La verificación práctica del grado en el cuál la funcionalidad y otros atributos del software satisfacen los requerimientos funcionales y no funcionales ha sido parte del proceso de desarrollo desde hace varias décadas. Sin embargo, sólo en la última década y como parte de nuevas propuestas de procesos de desarrollo (los procesos ágiles), el rol de las pruebas de software se ha ido extendiendo más allá de la clásica etapa de control de calidad típicamente ejecutada el final del ciclo de desarrollo justo antes de que el sistema entre en producción.

Desarrollo guiado por pruebas

Las pruebas y funcionalidad existente

Uno de los principios del desarrollo ágil de software señalaba que el cambio de los requerimientos es algo esperado; por lo tanto, el diseño de software debe facilitar la implementación de los cambios requeridos. Las pruebas automáticas de software ayudan a verificar que los cambios en el diseño no hayan afectado la funcionalidad del sistema; en este sentido, las pruebas de software promueven un escenario favorable a la mejora continua del diseño reduciendo el miedo a romper la funcionalidad del sistema como consecuencia de un rediseño. Entonces, mientras más exhaustiva la batería de pruebas, mayor cobertura para detectar posibles errores introducidos al reorganizar el código. En definitiva, una batería de pruebas automáticas incrementa la productividad (es posible verificar inmediatamente el efecto de un cambio sin recurrir a “tiempo de depuración”) y la calidad del software.

Las pruebas y nueva funcionalidad

Una de las maneras más efectivas para la construcción de una batería exhaustiva de pruebas automáticas es adoptar la práctica conocida como Desarrollo Guiado por Pruebas (Test Driven Development – TDD). TDD establece las siguientes reglas:

Primero, escribir una prueba automatizada antes de escribir el código necesario para implementar una nueva funcionalidad. En este momento la prueba actúa como la especificación de la funcionalidad indicando el comportamiento esperado y obviamente la prueba inicia en un estado fallido porque la funcionalidad aún no existe. Dependiendo de la complejidad de la funcionalidad, esta puede requerir de varias pruebas cada una centrada en un aspecto específico de la funcionalidad.
Segundo, escribir únicamente el código necesario para pasar la prueba. En este momento la prueba se ha convertido no sólo en la especificación sino en la documentación del software (expresada como ejemplos de uso).
Tercero, reorganizar/refactorizar el código para mejorar su diseño.

Repetir el ciclo anterior para ir desarrollando gradualmente la funcionalidad requerida:

Beneficios

Algunos de los efectos positivos resultantes de la aplicación de estas reglas son:

La especificación existe como código antes que la funcionalidad
La creación de las pruebas y la funcionalidad avanzan de manera casi paralela y sincronizada; no existe una fase de desarrollo y una de prueba.
En una sesión de desarrollo se intercalan periodos de diseño (creación de la especificación como una prueba) e implementación (el código necesario para pasar la prueba)
Crear las pruebas antes que la funcionalidad promueve el desarrollo de un diseño con una funcionalidad fácil de verificar