El Ciclo de Trabajo en TDD

En el ciclo de vida clásico en cascada las pruebas son posteriores al diseño y la codificación, esto implica que un fallo en las pruebas conlleva una vuelta atrás al paso de codificación o bien, retroceder dos pasos y tener que modificar nada menos que el diseño, los costes por retroceso son conocidamente altos. La idea principal de TDD es anteponer las pruebas a todo el proceso, por tanto un fallo en las pruebas no supone una vuelta atrás y se reduce su coste dado que los pasos de codificación y diseño se subordinan a ellas. Por otro lado también se invierte el orden de la codificación y el diseño, dado que de la codificación que supera las pruebas en ciclos repetidos un buen diseño debiera emerger de forma natural, claro está que deben controlarse los índices de calidad.

El objetivo inicial de una prueba es, curiosamente, que falle. En el mundo TDD una prueba que falla se representa con un icono rojo y una que se supera con uno verde. Dada una nueva característica implementamos la prueba, creamos el código justo y necesario para enlazar con la prueba y.. nos vamos a rojo. Tenemos algo muy valioso entre manos, nada menos que una prueba que falla conectada con un esqueleto de un código que no funciona, que es mucho más que no tener nada. Ahora nuestro objetivo es generar el código necesario para irnos a verde, prueba superada. Repitiendo el proceso una y otra vez veremos cómo las pruebas nos dirigen hacia la implementación final en pequeños pasos de integración.

Dos temas importantes se quedan en el aire y que veremos más adelante:

• Maneras de enlazar con las pruebas.
• Controlar la acumulación de código de mala calidad de un ciclo de pruebas al siguiente.

Por tanto, el ciclo de trabajo en TDD se puede representar por:

1) Escribir una prueba que falle.

2) Escribir código que supere la prueba.

3) Integrar el código eligiendo el mejor diseño que respete todas las demás pruebas anteriores.

Siguiendo este ciclo de trabajo conseguiremos que emerja un buen diseño, el código generado será demostrable ( pues tenemos pruebas de ello ), se tendrán garantías de respetabilidad del sistema en su globalidad siendo el diseño modular y cumplirá estar altamente cohesionado y bajamente acoplado. Claro está que todo ello depende directamente del tercer paso con el que vuelvo a repetir que es sumamente necesario:

• Controlar la acumulación de código de mala calidad de un ciclo de pruebas al siguiente.

Las técnicas utilizadas para garantizar la calidad del diseño y el código asociado se denominan técnicas de Refactorización, contenido que veremos más adelante y que bien pueden ser tratados como un tema a parte.