TDD

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. La disciplina solo paga cuando esos tests corren en cada cambio, por eso TDD y CI/CD son hermanos, no preocupaciones separadas.

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.

Ejemplo de dónde TDD se gana su coste frente a dónde es teatro: un módulo de conciliación de pagos tiene casos límite peliagudos (reembolsos parciales, redondeo de divisa, reintentos). Escribir el test que falla primero te obliga a declarar el comportamiento esperado antes de que exista el código, y la suite atrapa la regresión seis meses después cuando alguien «simplifica» el redondeo. Eso es TDD pagándose solo. Ahora contrasta un script de importación de datos desechable que borrarás en dos semanas: escribir tests primero ahí es puro overhead. La regla honesta es hacer TDD del código pesado en lógica y caro de equivocar y no del resto.

El error más común es tratar la cobertura como un objetivo. Persigue el 90 % y el equipo escribe tests para getters y setters para llegar al número mientras se salta los tests de integración donde viven los bugs reales. La cobertura es un diagnóstico útil y un objetivo terrible; es una métrica que se manipula. Wavect usa TDD donde paga: tests de integración para todo lo que tenga forma de dinero, tests de contrato para todo lo orientado al cliente, tests de aceptación estilo BDD donde producto necesita leerlos, tests unitarios para lógica no trivial. Probamos bien las partes difíciles, no todas las partes por igual, y lo tratamos como una práctica dentro de un loop agile sano en vez de una casilla que marcar.