Estrategias de prueba

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.

Puede concentrar las pruebas de componentes en las siguientes áreas:

Pruebas a nivel de subsistema

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.

Los dos tipos comunes de pruebas de integración son conocidos como descendente y ascendente.
  • Las pruebas descendentes empiezan al principio de la jerarquía del programa y se desplaza de arriba abajo por las ramas. Esto puede hacerse desde la vía más corta hasta el nivel más profundo, o a través de la jerarquía, antes de proceder al siguiente nivel. La ventaja principal de este tipo de prueba es que la arquitectura global del subsistema puede verse y probarse al principio. El inconveniente principal es la necesidad de utilizar apéndices hasta que se escriban los componentes de nivel inferior, lo que podría proporcionar resultados no muy fiables para los componentes de nivel superior.
  • Las pruebas ascendentes suelen empezar probando primero los componentes de nivel inferior de manera individual y después en clústeres. Esto asegura que se prueba cada componente por completo antes de que el componente llamante lo utilice. Este método tiene la ventaja de detectar errores en componentes críticos al principio del proceso de desarrollo. El inconveniente principal es que muchos o la mayoría de componentes deben construirse para que pueda presentarse un programa práctico. Los lenguajes orientados a objetos se prestan a las pruebas ascendentes.
  • Una tercera opción es seguir al pie de la letra la estrategia de diseño. Esto significa que cada componente se prueba a medida que se construye. La definición de pruebas forma parte del diseño del componente. Como parte de esta estrategia, puede tomar un enfoque descendente o ascendente.

Pruebas a nivel de clase

Las pruebas a nivel de clase ejercen las interacciones entre los métodos de una clase o un pequeño clúster de clases. La finalidad es verificar que la clase soporta todos los casos de uso que los clientes necesitan y que es lo suficientemente solvente para manejar secuencias de métodos inesperadas. Por los siguientes motivos, las pruebas a nivel de clase suelen estar consideradas como la manera más eficaz de probar software orientado a objetos:
  • Probar a nivel de clase es muy eficaz en términos de cobertura de código. Con unas pocas pruebas puede llegar al 60% o 70% de cobertura de código.
  • Las pruebas a nivel de clase refleja los servicios que proporciona la clase a sus clientes. Las pruebas son fáciles de escribir y pueden utilizarse como documentación para la clase.
  • Las pruebas a nivel de clase son el nivel de pruebas óptimo para buscar errores al principio del proceso de diseño.

Pruebas a nivel de método

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.

Pruebas de interfaces, clases abstractas y superclases

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.

Pruebas de EJB

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.

Pruebas de servicios Web

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

Condiciones de uso | Comentarios
(C) Copyright IBM Corporation 2000, 2004. Reservados todos los derechos.