Soy un fiel defensor de hacer tests y sobre todo de hacerlos antes de escribir una linea de código, pero no todo lo que hacemos tiene que estar hecho con TDD. Quizás el título sea un poco clickbait,.. en este post me gustaría que reflexionásemos sobre algunos aspectos a tener en cuenta de por qué Test Driven Development no es una bala de plata aunque ayuda mucho al diseño y de algunos temas interesantes alrededor del testing, refactoring y software.
"Cuando la única herramienta que tienes es un martillo, todo problema comienza a parecerse a un clavo".
No todo lo que hacemos tiene que estar hecho con TDD. ¡Pensar antes de escribir es mucho más importante! Por esta razón, estamos seguro de que es posible hacer buen software sin TDD. Aunque creo que hacer software sin TDD es más complicado porque no todo el mundo es capaz de pensar antes de escribir. Además a veces las “circunstancias” nos empujan a ir rápido, a tenerlo listo ya, o incluso a pensar (ilusos de nosotros) esto lo arreglamos más adelante. Del mismo modo, podemos llegar a un lugar oscuro si no nos planteamos a probar el software lo más pronto posible. Seguro que alguna vez nos ha pasado que llegamos a un una clase, servicio o feature que es difícil de probar. ¡eso sin duda es un “mal olor”! Quizás en el futuro ese mal olor acabe en algo podrido que y nos dé algún que otro dolor de cabeza. En cualquier caso cuando usamos TDD este nos provee de un proceso para analizar los problemas, para comprender qué es lo que está pasando, qué casos se nos pueden presentar, qué casos son excepcionales,….. además nos proporciona un arnés de seguridad para ir mejorando(refactor). Sin este proceso de TDD: hacer un test, comprobar que falla, hacer código para pasar el test y refactorizar, Lo qué tenemos es un proceso custom, donde cada miembro del equipo crea de manera distinta y por quizás lleguemos a situaciones en las que modificar un código se nos haga un poco cuesta arriba.
Continúa leyendo “TDD no sirve para todo pero ayuda”
