Menuda guerra ha ocurrido esta semana. Cómo decía un compañero, parecía una discusión de Salvame Deluxe pero en el mundo del desarrollo.

Todo empezó cuando David Heinemeier Hansson, padre del Ruby on Rails,  escribió un artículo sobre los problemas de usar TDD. David afirma que hacer TDD no es conveniente, que obliga a separar demasiados intefaces  y que es mejor hacer tests de integración más lentos que de todos modos, con paralelización y test en la nube se pueden hacer muchos a la vez.

Al poco, Bob Martin (Uncle Bob) respondió en su blog que unicamente cuando se aplica TDD se consigue reducir el tiempo de depuración, una documentación unequivoca en los tests y un desacoplamiento entre clases muy valioso por sí mismo. Poco después volvió a escribir explicando un poco más dónde no se puede usar TDD y dónde sí. De este modo respondía a las críticas que suelen surgir sobre la falta de aplicabilidad en algunos entornos.

El propio  Kent Beck, padre del TDD, escribió en facebook un supuesta nota postuma sobre el TDD, echando de menos la técnica y rogando poder encontrar otra que le diera la misma seguridad a la hora de escribir, la misma documentación y enfoque a la hora de escribir.

Personalmente el TDD es una herramienta que vale la pena conocer bien. Entiendo sus dificultades. En más dificil hacerlo bien que cualquier framework, IDE o incluso lenguaje. Requiere que el desarrollador dedique tiempo no a crear, que es lo que más le gusta, sino a poner redes de seguridad a lo que aún no ha empezado a escribir. En VSN no lo hacemos el 100% de las veces. Tenemos «sólo» un 40% de cobertura que nos ofrece ya una gran seguridad a la hora de añadir nuevas funcionalidades o refactorizar. Sin embargo, nada no nos impide intentar tener cada vez más cobertura y usar TDD cada vez en más ocasiones. Como alguien me dijo una vez, si intentas saltar tan alto como para tocar la luna lo más seguro es que nunca lo consigas, pero llegarás muchísimo más alto que si nunca lo hubieses intentado.