Idea principal

Escribir la prueba primero y el código después invierte el orden habitual, pero el interés no está en el orden. La prueba describe el qué: he aquí el comportamiento esperado, he aquí lo que debe seguir siendo verdad. El código describe el cómo. La primera es, por tanto, una pieza de la especificación, escrita en un lenguaje que la máquina puede evaluar.

Lo que esto cambia se ve con el tiempo. El código se refactorizará, se encontrará con nuevos datos, se añadirán otras funcionalidades a su alrededor. El comportamiento esperado, en cambio, queda fijado en otro sitio que en la memoria de quien lo implementó: si se rompe, la prueba se rompe, idealmente en el puesto del desarrollador o en preproducción antes que en producción.

El TDD no suprime los defectos, no sustituye a la reflexión de producto, y no convierte una mala especificación en un buen producto. Hace una sola cosa, y es poco común: vuelve verificable una parte de la calidad antes de que el código exista.

Por qué es importante

Esto saca la disciplina del registro de la higiene técnica. Una prueba escrita antes es un artefacto de especificación, y por tanto un lugar donde producto y desarrollo pueden ponerse de acuerdo sobre un comportamiento, algo que un documento en prosa no permite, por no ser evaluable.

Desplaza también el coste de las pruebas: escritas después, constatan lo que el código hace; escritas antes, restringen lo que deberá hacer.

Matices y límites

La parte formalizable es estrecha. Una prueba dice que un comportamiento se cumple, nunca que era el comportamiento correcto al que apuntar: la porción de calidad que depende del juicio de producto queda intacta.

Y la disciplina supone que se sepa enunciar el comportamiento esperado. Ante una especificación demasiado vaga, escribir la prueba primero no aclara nada: congela la ambigüedad en lugar de resolverla.

Preguntas abiertas

• ¿Qué parte de los comportamientos esperados de una funcionalidad es realmente expresable en una prueba, y qué ocurre con la parte que no lo es?