“No tenemos tiempo para tests.” En 8 años trabajando con equipos de desarrollo, esta frase es la más repetida y la más cara. Cara en deuda técnica, cara en bugs, cara en velocidad de desarrollo a los 6 meses.
La ironía es que los equipos que dicen no tener tiempo para tests son exactamente los equipos que menos tiempo tienen: están demasiado ocupados apagando fuegos que un test habría evitado.
Por qué el “no hay tiempo” es una trampa de percepción
El error está en ver los tests como algo que se añade al desarrollo en lugar de algo que cambia cómo desarrollas. Con TDD no escribes el código y luego los tests. Escribes el test primero, y el test define qué tiene que hacer el código.
El efecto práctico: el tiempo que “pierdes” escribiendo el test lo recuperas porque:
- Sabes exactamente qué tienes que implementar antes de empezar
- El debugging se reduce drásticamente (el test falla en el sitio exacto del problema)
- Los refactors no dan miedo porque la suite te cubre las espaldas
- La integración con otros módulos falla en CI, no en producción
La curva de adopción tiene un coste inicial real. Las primeras dos semanas son más lentas. La semana tres empieza a equilibrarse. A partir del mes dos, los equipos son más rápidos que antes, no más lentos.
El ciclo Red-Green-Refactor en 3 minutos
TDD funciona en un ciclo de tres pasos que se repite en bucle:
- Red: escribe un test que describe el comportamiento que necesitas. Ejecútalo. Falla (rojo). Si no falla, o el test está mal, o la funcionalidad ya existe.
- Green: escribe el código mínimo necesario para que el test pase. No más. No te preocupes aún por elegancia.
- Refactor: con el test en verde, limpia el código. Renombra, extrae funciones, elimina duplicaciones. El test te protege. Si algo se rompe, lo sabes al instante.
Cada ciclo dura entre 3 y 15 minutos. Se repite decenas de veces al día. El resultado es código que siempre tiene un test que lo respalda porque ese test fue la condición necesaria para que el código existiera.
El plan de adopción: 4 semanas sin paralizar el equipo
La clave del plan es que no tocamos el código existente en las primeras semanas. Empezamos solo con código nuevo. Esto elimina el miedo a romper cosas y permite que el equipo aprenda el ciclo sin presión.
Semana 1: regla del código nuevo
Una sola regla: cualquier funcionalidad nueva que se empiece esta semana se desarrolla con TDD. Solo código nuevo. Nada de retrofitting. En esta semana también se configura el entorno: framework de testing elegido (Jest + Testing Library para TypeScript, pytest para Python), integración con CI para que los tests bloqueen el merge si fallan.
Semanas 2 y 3: la regla del scout
Al arreglar cualquier bug, antes de tocar el código, se escribe un test que reproduce el bug. El test falla (rojo). Se arregla el bug. El test pasa (verde). El bug no puede volver sin que el test lo detecte.
Esta es la adopción más rentable del TDD: cada bug reparado se convierte automáticamente en cobertura. Al final del mes, los módulos más frágiles son los que más tests tienen.
Semana 4 en adelante: refactor guiado
Con una base de tests creciente, empiezan los refactors con confianza. Se identifican las partes del código con mayor deuda técnica y se abordan incrementalmente: un test que cubre el comportamiento actual, refactor, test en verde. Nunca se refactoriza sin cobertura.
Métricas para saber si va bien
- Cobertura de código nuevo: debería alcanzar el 80%+ en la semana 3
- Tiempo medio de debugging: debería reducirse entre un 30-50% en el primer mes
- Bugs en producción en módulos con tests: debería tender a cero
- Velocidad de sprint: puede bajar un 10-15% en las primeras dos semanas, se recupera y supera la base a partir de la semana 5-6
Lo que no funciona
El TDD falla cuando se impone sin formación, cuando los tests se escriben para cubrir métricas y no para cubrir comportamiento, y cuando el setup del entorno es tan complejo que cada test requiere 40 líneas de boilerplate.
La diferencia entre un equipo que adopta TDD con éxito y uno que lo abandona en dos semanas no es la disciplina: es el setup inicial y el acompañamiento. Con el entorno correcto, los equipos no vuelven a desarrollar sin tests. No porque sea obligatorio, sino porque han visto lo que supone sin ellos.