El debate sobre si TDD está muerto o no sigue vivito y coleando, y tras una guerra fría de artículos por ambas partes, ahora el intercambio de opiniones se ha pasado a un formato de vídeo debate donde Martin Fowler, Kent Beck y el mismísimo David Heinemeier Hansson hablan sobre el tema.
La verdad es que cuando anunciaron que Kent Beck iba a enfrentarse a David Heinemeier sobre el tema TDD, me alegré bastante por ver a gente tan buena en esto que hacemos debatiendo sobre distintas metodologías. “Seguro que aprendo de ambas partes“, pensaba yo.
Ingenuo de mí.
Tres hangouts despues, la idea general que para mí resume el debate es que DHH dice que TDD puede desencadenar en mal código. El problema fundamental que tiene su argumento es que esto no es exclusivo de TDD. Hacer TDD te puede llevar a un mal código de la misma manera que utilizar mal cualquier otra herramienta podría llevarnos por el mal camino.
Tests como herramientas de diseño
A veces parece que lo que no le gusta de TDD y de los tests unitarios, es que a diferencia de los tests de sistema que él prefiere, los unitarios son tests que no te ocultan los problemas que tiene tu código. No puedes crear un tests en aislamiento cuando tu clase tiene mil dependencias y no cumples cosas como la ley de Demeter o los principios SOLID. Sin embargo, los tests de sistema no se quejarán en absoluto. No son nada exigentes en ese sentido. A cambio, ¿qué pierdes? Pierdes feedback instantáneo sobre cómo de bien (o mal) estás diseñando algo. Pierdes velocidad en los tests que pasan de segundos a minutos.
Eligiendo el camino de los tests de sistema puede dar la impresión de que vamos más rápido porque tenemos que pensar menos los tests, pero lo que realmente estamos haciendo es esconder el polvo debajo de la alfombra. El problema es que llegará un día que la alfombra no será suficiente, y cuando nos queramos dar cuenta, las termitas han tomado el lugar.
Arquitectura Hexagonal
Otro argumento que me chocó de DHH, que menciona en el segundo hangout, es ese que dice que TDD penaliza el diseño porque tiendes a cosas como la arquitectura hexagonal. Para empezar, no entiendo qué relación tiene una cosa con la otra. Puedes hacer una arquitectura hexagonal sin hacer TDD y viceversa.
Además, dice que elegimos utilizar arquitectura hexagonal porque nos ayuda a crear tests. Que el principal motivo de este tipo de arquitectura es el testing.
En mi charla sobre arquitectura hexagonal (slides), no se mencionan los tests hasta la slide número 55 (son 60). Y lo que digo es que la facilidad de hacer tests con este tipo de arquitecturas, es un buenísimo efecto secundario que tendremos. Pero nunca se vende que sea el principal motivo. Cierto es que en el artículo original se hace más hincapié en los tests, pero para mí la principal ventaja es la independencia de herramientas: frameworks, bases de datos, etc,. además de promocionar al dominio a un sitio más visible y acorde a la importancia que tiene.
Conclusión
Me veré el último hangout, porque siempre se puede aprender algo de estas tres fieras, pero para mi, el debate no se ha llevado en ningún momento por cauces interesantes. Prefiero no pensarlo, pero ya van varias personas que mencionan que DHH solo pretendía hacer ruido. Espero que no fuese así.