Metodología y Componentes Esenciales del Testing Unitario de Software

Fundamentos de las Pruebas de Unidad (Unit Testing)

Las pruebas de unidad se centran en el componente más pequeño del software, conocido como módulo (métodos, funciones, procedimientos, triggers). Fundamentalmente, se buscan errores utilizando técnicas de caja blanca, y es conveniente que este proceso se realice de forma paralela para diferentes módulos.

Áreas Críticas en la Prueba de Módulos

Al probar los módulos, es crucial incidir en cinco partes distintas:

1. Prueba de Interfaz (Comunicación): Comprueba que las llamadas y las respuestas del módulo son correctas, verificando que todo lo que entra y sale del módulo es correcto.
2. Estructuras Locales de Datos: Comprueba que los datos definidos localmente dentro del módulo conservan su integridad.
3. Condiciones Límite: Comprueba que el módulo funciona bajo situaciones límite.
4. Caminos Básicos: Comprueba que, como mínimo una vez, se ejecutan todos los caminos lógicos.
5. Caminos de Mapeo de Error: Comprueba que si se produce un error, existe algún mecanismo o rutina para capturarlo y depurarlo.

Mecanismos y Variables Adicionales

Además de las estructuras locales de datos, también es conveniente, en las pruebas de unidad, comprobar cómo afectan las variables globales a ese módulo. La prueba del camino básico y las pruebas de bucles son mecanismos efectivos en la prueba de la unidad.

El Entorno de la Prueba de Unidad

Un módulo no es un programa independiente y no se puede ejecutar por sí solo. Por este motivo, es necesario desarrollar un software específico para probarlo.

Figuras Clave en el Software de Prueba

Dentro de este software existen dos figuras esenciales:

El Conductor (Driver)

Aparece por encima del módulo y es un elemento que hace la función de llamar a ese módulo. Es una especie de programa principal que tiene como misión pasarle datos de entrada al módulo y recoger los resultados de este.

El Resguardo (Stub)

Puede o no aparecer. Su misión es sustituir a los subprogramas o módulos inferiores a los que llama ese módulo. Debe diseñarse con el mismo interfaz (comunicación, parámetros) que los módulos subordinados a los que sustituye. Su misión es recoger los datos del módulo a probar, manipularlos mínimamente y devolver lo que se espera.

Flujo de Interacción

El proceso de interacción se resume de la siguiente manera:

• El Conductor recogerá unos datos y se los pasará al módulo en la llamada (parámetros de entrada al módulo que estamos probando).
• Los Resguardos recibirán datos del módulo, los manipularán de forma artificial y se los devolverán al módulo.
• Al concluir, el módulo devolverá los datos al Conductor (parámetros de salida o valores devueltos por el módulo que estamos probando).

La creación de Conductores y Resguardos es una carga de trabajo y un coste adicional en las pruebas de unidad.