TDD (Test-Driven Development, o desarrollo guiado por pruebas) es una técnica que Kent Beck popularizó a finales de los años 90 como parte de Extreme Programming: en vez de escribir el código y después los tests que lo verifican, se invierte el orden. Se escribe primero un test que falla, después el código mínimo para que pase, y solo entonces se mejora el diseño. No es (solo) una forma de conseguir cobertura de tests, es una forma de diseñar software un paso a la vez.
El ciclo rojo-verde-refactor
El proceso se resume en tres pasos que se repiten constantemente. Rojo: escribir un test para la siguiente pequeña pieza de funcionalidad, y verlo fallar, porque el código todavía no existe. Verde: escribir el código más simple posible que haga pasar ese test, sin preocuparse todavía de que sea elegante. Refactor: con la seguridad de tener un test en verde, limpiar tanto el código nuevo como el que ya existía, sabiendo que si algo se rompe el test lo va a avisar de inmediato.
Por qué escribir el test primero cambia algo
La diferencia no es solo de orden. Escribir el test antes obliga a pensar primero en cómo se va a usar una función o una clase —su interfaz— antes de pensar en cómo se va a implementar por dentro, lo que suele producir un diseño más simple de usar. También da un ciclo de feedback muy corto: en vez de escribir cientos de líneas y descubrir el problema al final, cada fallo aparece segundos después de introducirlo. Con el tiempo esto reduce también las sesiones largas de debuggear en producción, porque la mayoría de errores se detectan mucho antes de llegar ahí. Y escribir el test primero empuja hacia funciones pequeñas con una sola responsabilidad clara, que es justo uno de los pilares del clean code.
Errores comunes al empezar
El más habitual es perseguir el 100% de cobertura como si fuera el objetivo en sí mismo, cuando el objetivo real es que los tests den confianza para cambiar el código sin miedo; un test que solo existe para subir el porcentaje no aporta eso. Otro error es testear detalles internos de implementación en vez de comportamiento observable, lo que hace que los tests se rompan con cualquier refactor aunque el comportamiento siga siendo correcto. Y un tercero es intentar aplicar TDD de golpe a todo un proyecto grande y heredado, en vez de empezar por una función pura y aislada donde el ciclo rojo-verde-refactor es rápido de practicar.
Cuándo tiene sentido (y cuándo no)
TDD funciona especialmente bien en lógica de negocio con reglas claras y comportamiento verificable: cálculos, validaciones, transformaciones de datos. Es menos claro su valor en código muy exploratorio, prototipos que se van a desechar, o interfaces visuales donde el comportamiento correcto es difícil de expresar como una aserción. Esto no es una opinión aislada: Kent Beck, Martin Fowler y David Heinemeier Hansson debatieron públicamente estos límites en "Is TDD Dead?", y la conclusión compartida fue que es una herramienta muy valiosa, no una regla que deba aplicarse sin criterio en cualquier situación. Una suite de tests bien escrita también hace que el code review sea más rápido, porque quien revisa puede confiar en que el comportamiento ya está verificado en vez de tener que imaginárselo leyendo el código. Y aunque TDD no elimina la deuda técnica, sí la hace más visible: cuando un test se vuelve difícil de escribir, suele ser la primera señal de que el diseño se está complicando más de la cuenta.
Fuentes:
Comentarios (0)
Deja un comentario
No hay comentarios aún. ¡Sé el primero en comentar!