Desarrollo guiado por tests

¿Qué es el desarrollo guiado por tests?

La vieja costumbre es «escríbelo primero, pruébalo después». El desarrollo guiado por tests (TDD) lo invierte: primero escribes un test que falla, luego el mínimo código para que pase, y al final refactorizas para limpiar. El ciclo se llama «rojo-verde-refactor»: rojo es test fallando, verde es test pasando.

¿Por qué escribir el test primero?

Te obliga a definir el requisito
Antes de escribir el test tienes que decir exactamente qué debe hacer el código — sin adivinar sobre la marcha.
Cada paso tiene red de seguridad
Cada función tiene un test vigilándola. Rompes algo y se pone rojo al instante, así los problemas salen pronto.
Impulsa un mejor diseño
Para que el código sea comprobable, acabas escribiendo una estructura más modular y desacoplada.

¿Cuál es el ciclo central?

Rojo
Escribe un test que describa el comportamiento que quieres, ejecútalo y mira cómo falla: eso demuestra que el test funciona.
Verde
Escribe el mínimo código para que el test pase. No optimices todavía.
Refactor
Sin cambiar el comportamiento, ordena el código para que sea más claro y fácil de mantener, con los tests cubriéndote.

¿Es para todo el mundo?

TDD es más lento al principio, y puede resultar pesado para principiantes o en proyectos exploratorios con requisitos cambiantes. Pero la confianza que da vale la pena: la suite de regresión es una red de seguridad. En bases de código longevas, lógica de backend y algoritmos centrales es donde más renta.

En resumen: el desarrollo guiado por tests es «pon la regla primero, escribe el código después» — los tests que fallan sacan código correcto y limpio.