METODOLOGÍA

TDD

Test-Driven Development

Escribe el test primero. Mira cómo falla. Escribe el código que lo hace pasar. Refactoriza. Repite.

Última revisión: 2026-05-24 porKevin Riedl wiki ↗

Test-Driven Development es una disciplina, no una metodología. El loop es: rojo (escribir un test que falla), verde (escribir el código más simple que pase), refactor (limpiar sin romper el test). Hecho al pie de la letra, produce código con cobertura de tests muy alta y una función de fuerza contra el over-engineering.

Por qué la mayoría de los equipos dicen que hacen TDD pero no lo hacen: escribir el test primero se siente más lento en el momento. El payoff (seguridad para refactorizar, cobertura de regresión, presión de diseño hacia unidades pequeñas) llega meses después. Para entonces el equipo dejó de escribir los tests primero y se convenció de que nunca marcó la diferencia.

Wavect usa TDD donde paga: tests de integración para todo lo relacionado con dinero, tests de contrato para todo lo orientado al cliente, tests unitarios para lógica no trivial. No escribimos tests para getters y setters. La cobertura como objetivo es una métrica que se manipula.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Escribir el test después del código y llamarlo TDD. El test pasa porque el código ya existe; no hubo rojo, no hubo presión de diseño. Es cobertura, no test-driven. Si el equipo no recuerda la última vez que un test falló al escribirlo, no están haciendo TDD.
No. Es una métrica que se manipula. Cobertura alta con asserts triviales es peor que cobertura media con asserts que de verdad detectan regresiones. Lo que mide es si el código se ejecuta durante los tests, no si el comportamiento se está verificando. Mide mutation testing si quieres una señal honesta.
Prototipos exploratorios y código de UI donde el comportamiento se descubre mientras se prueba visualmente. Forzar TDD ahí ralentiza el aprendizaje. Pasa a TDD cuando el comportamiento se estabiliza y refactorizar sin red empieza a doler.