- No escribas ni una sola línea de código a no ser que antes tengas un test automatizado que falle.
- Elimina duplicados.
Las dos reglas anteriores nos llevan al siguiente orden de tareas:
- Escribe un test que falle.
- Programa el mínimo código necesario para que el test deje de fallar.
- Refactoriza para eliminar cualquier posible duplicación surgida en los tests o en el código.
Este Red/Green/Refactor es el "mantra" del TDD.
Estos pasos se repiten una y otra vez hasta que se acaban los requisitos.
¿Cómo escribimos un test para un código que todavía no existe?
Respondamos con otra pregunta: ¿Acaso no es posible escribir una especificación antes de implementarla?
El hecho de tener que usar una funcionalidad antes de haberla escrito le da un giro de 180 grados a la forma de trabajar.
La esencia de TDD es sencilla pero ponerla en práctica correctamente es cuestión de entrenamiento, como tantas otras cosas.