TDD
El desarrollo guiado por pruebas (Test-Driven Development, TDD) es una práctica de ingeniería de software que invierte el orden habitual de trabajo: primero se escribe una prueba automatizada que describe el comportamiento que se quiere implementar, después se escribe el código mínimo necesario para que esa prueba pase, y finalmente se refactoriza el código para mejorar su estructura sin cambiar su comportamiento. Este ciclo breve se repite continuamente durante el desarrollo.
La práctica es atribuida a Kent Beck, quien la describió como parte central de Extreme Programming (1999) y la desarrolló en detalle en su libro Test-Driven Development: By Example (2003). Beck describía TDD como una forma de generar diseños simples e inspirar confianza en el código.
El ciclo rojo-verde-refactorizar
El ciclo de TDD se describe habitualmente con tres colores: Rojo: escribe una prueba que falla porque la funcionalidad aún no existe. La prueba fallida (roja) es el punto de partida: define qué debe hacer el código. Verde: escribe el código mínimo necesario para que la prueba pase. Solo el código mínimo: nada más, aunque parezca "feo" o provisional. Refactoriza: mejora la estructura interna del código sin cambiar su comportamiento externo. Las pruebas garantizan que la refactorización no ha roto nada. Este ciclo dura minutos, no horas. La disciplina de mantenerse en ciclos cortos es lo que hace efectivo a TDD.
Qué aporta TDD
Cobertura de pruebas desde el principio: como las pruebas se escriben antes que el código, cada funcionalidad tiene su prueba desde el primer día. No hay código sin prueba. Diseño emergente: escribir la prueba antes de implementar obliga a pensar en cómo se usará el código (su interfaz) antes de pensar en cómo funcionará internamente. Esto tiende a producir diseños más simples y desacoplados. Refactorización segura: con una suite de pruebas completa, el equipo puede refactorizar con confianza. Si algo se rompe, las pruebas lo detectan inmediatamente. Reducción de deuda técnica: el ciclo rojo-verde-refactorizar incorpora la mejora continua del código como parte del proceso normal de desarrollo, no como una tarea separada que "se hará cuando haya tiempo". Documentación ejecutable: las pruebas describen el comportamiento esperado del sistema de forma precisa y verificable. Son una forma de documentación que no puede quedar desactualizada: si el código cambia, las pruebas lo detectan.
Relación con BDD
El Behavior-Driven Development (BDD) es una extensión de TDD que usa un lenguaje más expresivo (como Gherkin: Dado / Cuando / Entonces) para escribir las pruebas de forma que sean comprensibles también para personas no técnicas. Los criterios de aceptación escritos en formato BDD son directamente ejecutables como pruebas. TDD y BDD son complementarios: TDD se aplica a nivel de unidad, BDD a nivel de comportamiento del sistema.
TDD con herramientas de IA
La IA generativa está cambiando cómo los equipos aplican TDD en la práctica:
- Generación de pruebas asistida: los asistentes de código (GitHub Copilot, Cursor) pueden sugerir pruebas unitarias a partir de la descripción de una función. Esto acelera la escritura de pruebas para código ya existente, aunque no sigue estrictamente el orden de TDD.
- TDD con IA como par: algunos equipos usan la IA para generar el código que pasa una prueba ya escrita por el desarrollador, manteniendo así el ciclo rojo-verde-refactorizar con asistencia.
El mayor riesgo de usar IA en TDD es invertir el ciclo: que la IA genere el código primero y las pruebas después, como verificación en lugar de como especificación. Esto elimina el beneficio de diseño que aporta TDD: escribir la prueba primero obliga a pensar en el comportamiento esperado antes de pensar en la implementación. Con IA generando el código primero, ese pensamiento previo desaparece y el código tiende a ser más complejo y acoplado.
Error frecuente
Aplicar TDD solo a funcionalidades nuevas y no a la corrección de errores. Un error en producción es una prueba que falta: el comportamiento incorrecto no estaba cubierto. La práctica recomendada es escribir primero una prueba que reproduzca el error, verificar que falla (rojo), corregir el código hasta que pase (verde), y entonces refactorizar. Esto garantiza que ese error no volverá a ocurrir sin ser detectado.
Referencias
Beck, Kent. (2003). Test-Driven Development: By Example. Addison-Wesley. Beck, Kent; Fowler, Martin. (1999). Planning Extreme Programming. Addison-Wesley.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.