Herramientas para la gestión de las Pruebas del Sistema

Ha llegado el momento de definir las pruebas que se realizarán para verficar y validar el sistema. En este post vamos a hablaros de una herramienta que facilita notablemente la realización de las pruebas definidas en el Documento de Pruebas del Sistema (o en el de Diseño del Sistema, según si se han integrado ambos o no) en entorno Java: JUnit.

Normalmente el conjunto de pruebas se realiza a partir de la especificación de lo que se espera de un programa, de ahí se pasa a preparar una batería de casos de prueba. Para programas pequeños (como solía venir siendo hasta ahora en nuestra carrera universitaria) éstos se pueden escribir en papel y ejecutarse disciplinadamente de forma manual, algo factible si se han de realizar, por decir una cifra, unos veinte tests. Pero si nos enfrentamos a un problema mucho más grande, con cientos de pruebas que llevar a cabo, es conveniente automatizar este proceso, de forma que se puedan realizar muchas veces, tanto durante la fase de desarrollo como durante la de aceptación.

JUnit es un framework que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Esto se refleja en la respuesta del mismo: en función de algún valor de entrada se evalúa el valor de retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que regresó el método durante la ejecución, se devolverá un fallo en el procedimiento correspondiente.

El concepto fundamental en esta herramienta es el caso de prueba (test case), y la suite de prueba (test suite). Los casos de prueba son clases o módulos que disponen de métodos para probar los métodos de una clase o módulo concreta/o. Así, para cada clase que quisiéramos probar definiríamos su correspondiente clase de caso de prueba. Mediante las suites podemos organizar los casos de prueba, de forma que cada suite agrupa los casos de prueba de módulos que están funcionalmente relacionados.

Las pruebas que se van construyendo se estructuran así en forma de árbol, de modo que las hojas son los casos de prueba, y podemos ejecutar cualquier subárbol (suite) de forma recursiva.
De esta forma, construimos programas que sirven para probar nuestros módulos, y que podremos ejecutar de forma automática. A medida que la aplicación vaya avanzando, se dispondrá de un conjunto importante de casos de prueba, que servirá para hacer pruebas de regresión. Eso es importante, puesto que cuando cambiamos un módulo que ya ha sido probado, el cambio puede haber afectado a otros módulos, y sería necesario volver a ejecutar las pruebas para verificar que todo sigue funcionando. Esto último es básico en grandes sistemas donde la reingeniería es un proceso constante y se llevan a cabo múltiples modificaciones en el sistema, que pueden afectar al resto del mismo.

En la imagen anterior vemos un ejemplo de batería de pruebas realizado con JUnit, donde indica la cantidad de test realizados, los que fallan y los que son pasados con éxito.