Definir una estrategia de prueba le ayuda a centrar los recursos de prueba en las porciones de código adecuadas en el momento adecuado.
Al desarrollar aplicaciones de tamaño medio o tamaño grande, la primera pregunta que se plantea es "¿Por dónde empiezo?", seguida de "¿y ahora qué?". La guía viene en forma de métricas que le ayudan a analizar la complejidad y fiabilidad de los métodos, clases y componentes sometidos a prueba (CUT) y a decidir su estrategia.
Las pruebas de componentes, al contrario que las pruebas funcionales, se concentran en componentes de software individuales: clases o métodos así como Enterprise JavaBeans (EJB) y componentes del servicio Web. La finalidad de las pruebas de componentes es aislar cada componente para poder asegurar que funciona correctamente. Si es necesario, puede utilizar apéndices para sustituir otros componentes, condicionando así los resultados de la prueba al comportamiento del componente sometido a prueba. Una vez haya creado una suite de pruebas fiable, puede volver a ejecutarla regularmente para asegurarse de que no se produce una regresión del CUT.
El ámbito de las pruebas a nivel de subsistema (también denominadas pruebas de integración) es probar un conjunto de clases integradas que deben cooperar para proporcionar algún servicio. En un entorno multinivel, un subsistema podría ser uno de los niveles. El objetivo de las pruebas a nivel de subsistema es verificar las interfaces entre el componente sometido a prueba y otros subsistemas. Estas pruebas ejercen las interacciones entre los distintos objetos del subsistema.
Aunque las pruebas a nivel de subsistema deberían tener un rol significativo en el planteamiento global de pruebas, complemente las pruebas a nivel de subsistema con pruebas a nivel de método y a nivel de clase. Centrarse solamente en las pruebas a nivel de subsistema proporcionaría una cobertura superficial de las pruebas ya que no le ofrece suficiente control sobre las clases individuales.
Las pruebas a nivel de método ejercen las distintas condiciones definidas en el código de método en aislamiento de cualquier otro método. La finalidad es, generalmente, asegurarse de que el método procesa correctamente todas las entradas posibles. En muchos casos, probar una serie de métodos en aislamiento proporciona una cobertura de pruebas incompleta y, algunos métodos tales como los métodos privados, no pueden probarse en aislamiento. (Los métodos privados pueden tener una repercusión importante sobre el estado de un objeto y pueden cambiar el comportamiento de otras invocaciones de métodos.)
Las interacciones entre los métodos de una clase son una fuente común de problemas y la mejor manera de descubrir estos problemas es ejercer los métodos en diversos casos prácticos. Por consiguiente, siempre deberá combinar las pruebas a nivel de método con las pruebas a nivel de clase o subsistema, o ambos. En algunos casos, por ejemplo las pruebas de clases sin estado, puede centrarse exclusivamente en las pruebas a nivel de método, pero en otros casos podría decidir evitar las pruebas a nivel de método y centrarse solamente en las pruebas a nivel de clase.
La clave para una pruebas satisfactorias a nivel de método es determinar qué métodos deben probarse realmente. La tabla siguiente proporciona respuestas a algunas de las preguntas más frecuentes sobre las pruebas a nivel de método:
Pregunta | Respuesta |
---|---|
¿Qué sucede si el método se hereda de una superclase? | Si el método se hereda de una superclase y ya se ha probado como parte de la superclase, no es necesario realizar pruebas a nivel de método de este método en el contexto del objeto heredado. No obstante, deberá seguir utilizando este método en el contexto de las pruebas a nivel de clase del objeto heredado. |
¿Qué sucede si el método altera temporalmente el método de una clase padre? | Si se ha probado el método en el contexto de una clase padre, es necesario volver a probar el método que altera temporalmente. |
¿Qué sucede si el método queda sobrecargado o alterado temporalmente? | Un método queda sobrecargado cuando múltiples métodos de la misma clase tienen el mismo nombre pero distintos parámetros. Un método queda alterado temporalmente cuando se declara en una clase y su implementación se define o se altera en una subclase. Los métodos alterados temporalmente permiten que un tipo de objeto sea de naturaleza polimorfa. En cualquiera de los casos, asegúrese de probar cada implementación de estos métodos de clase individualmente. |
Puede utilizar pruebas abstractas para probar interfaces Java, clases abstractas y superclases. Aunque las clases abstractas no pueden ejecutarse por sí solas, puede aplicar una prueba abstracta a cualquier clase que implemente una interfaz, que realice una clase abstracta o que herede de una superclase.
Probar un Enterprise Java Bean (EJB) consiste generalmente en verificar la lógica comercial del EJB y el éxito o fracaso de sus métodos de ciclo de vida. Esto se hace probando los métodos definidos en la clase de bean llamando a los métodos mediante sus diversas interfaces. Las pruebas pueden residir en el mismo contenedor que el EJB o fuera del servidor de aplicaciones.
La mejor manera de probar un EJB es desplegarlo en un servidor de aplicaciones y ejecutarlo en el contexto de su contenedor. Si el EJB tiene una interfaz local, debe probarlo desde dentro del mismo servidor de aplicaciones, por ejemplo, utilizando otro EJB. Si el EJB tiene una interfaz remota, puede probarlo con un cliente de Java que se ejecute fuera del servidor de aplicaciones (a expensas de un aumento del tráfico en la red). En cualquiera de los casos, será necesario aislar componentes llamados por el EJB sometido a prueba para poder aislar el comportamiento del EJB.
Puede probar beans de sesión y beans de entidad construidos de acuerdo con la especificación de Enterprise JavaBeans 1.1 o 2.0. Puede probar beans de sesión y beans de entidad con estado y sin estado con persistencia gestionada por contenedor o persistencia gestionada por bean (CMP o BMP). Para probarlos, todos los beans deben tener una interfaz remota o local. La prueba de beans controlados por mensajes no está soportada actualmente.
Varios patrones de pruebas simplifican el proceso de probar EJB.
Al probar componentes distribuidos tales como servicios Web, el enfoque es básicamente el mismo que para probar cualquier otro componente. El objetivo de la prueba es estimular un servicio Web en ejecución en un servidor de aplicaciones y verificar que las respuestas del servidor coinciden con los valores de retorno esperados.
La interfaz de servicio Web, tal como se describe en un documento de descripción de servicios Web (WSDL), es una entrada necesaria para generar automáticamente una prueba de componentes para un servicio Web.
Conceptos relacionados
Subsistemas Java
Técnicas de prueba basada en estado
Tareas relacionadas
Probar métodos Java
Probar clases Java