TDD (Test-Driven Development) y el Ciclo Red-Green-Refactor
El Desarrollo Guiado por Pruebas (Test-Driven Development - TDD) es una disciplina fundamental del Software Craftsmanship. Al contrario de lo que sugiere su nombre, TDD no es principalmente una técnica de control de calidad o testing, sino una metodología de diseño y arquitectura de software.
Al escribir las pruebas antes del código de producción, nos obligamos a pensar en la usabilidad de la API, en la claridad de las interfaces y en la separación de responsabilidades desde el primer minuto.
1. El Ciclo Rojo – Verde – Refactorizar #
1┌────────────────────────────────────────────────────────┐ 2 │ │ 3 ▼ │ 4┌──────────────┐ ┌──────────────┐ ┌───────────┴──┐ 5│ 1. ROJO │ ───────► │ 2. VERDE │ ───────► │ 3. REFACTOR │ 6│ (Escribir un │ │ (Hacer pasar │ │ (Limpiar el │ 7│ test que │ │ la prueba lo │ │ código sin │ 8│ falle) │ │ antes posible│ │ romper tests)│ 9└──────────────┘ └──────────────┘ └──────────────┘
- 🔴 ROJO (Red): Escribe una prueba unitaria pequeña que describa el siguiente incremento de comportamiento deseado. La prueba debe fallar (o no compilar).
- 🟢 VERDE (Green): Escribe la menor cantidad posible de código de producción para que la prueba pase a verde. En este paso se permiten soluciones provisionales (Fake it till you make it).
- 🔄 REFACTORIZAR (Refactor): Con la red de seguridad de los tests en verde, limpia el código: elimina duplicación, mejora nombres, extrae métodos y aplica principios SOLID.
2. Las Tres Leyes de TDD (Robert C. Martin) #
Para interiorizar la disciplina de TDD, Uncle Bob formuló tres reglas estrictas que rigen el bucle de desarrollo en intervalos de segundos o minutos:
- Primera Ley: No escribirás código de producción a menos que sea para hacer pasar un test unitario que esté fallando.
- Segunda Ley: No escribirás más de un test unitario del suficiente para fallar (y no compilar cuenta como fallar).
- Tercera Ley: No escribirás más código de producción del necesario para hacer pasar el test que actualmente está fallando.
3. Ejemplo Práctico: Kata FizzBuzz paso a paso #
Resumen del tema
Conceptos clave #
- Diseño Emergente: TDD produce código naturalmente modular y desacoplado, porque un código acoplado es imposible de testear primero.
- Confianza para Refactorizar: permite mejorar el diseño en cualquier momento sabiendo que si se rompe algo, un test fallará al instante.
- Especificación Ejecutable: la suite de tests unitarios actúa como la documentación viva más precisa y actualizada del comportamiento del sistema.
Qué debes recordar #
El paso de Refactorización en el ciclo TDD es obligatorio, no opcional. Escribir tests sin refactorizar produce código sucio con tests.