TDD no sirve para todo pero ayuda

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”

TDD – ¿De adentro hacia afuera o de fuera hacia adentro?

Hace unas semanas estuve en un Merendojo de Madrid Software Craftmanship (desde aquí gracias a los organizadores Luís, Pablo y el resto de personas) y después de la kata estuvimos discutiendo distintos enfoques sobre como afrontar el problema. En un momento de la conversación surgió el tema de como afrontar los tests, por donde empezar, desde dentro hacia afuera, haciendo test desde la parte más externa posible,… la verdad es que la charla fue bastante interesante y me picó la curiosidad sobre como afrontar los tests y como hacer TDD cuando tienes un problema grande. Así que buscando en Internet encontré este interesante post TDD – From the Inside Out or the Outside In? de Georgina Mcfadyen y me he animado a hacer una traducción libre.

A menudo la parte más difícil de programar es saber por donde empezar. Haciendo TDD (Test Driven Development) la mejor lugar de empezar es con un test, pero estar delante de una página en blanco puede ser desalentador.

3389073921_63559084e0_z
Tobias Toft

¿La mejor manera de empezar es por los detalles de lo que está construyendo, y dejar que la arquitectura vaya emergiendo con un enfoque de adentro hacia afuera (Inside Out)? O bien, empezar por algo grande y dejar que los detalles vayan revelando a medida que se van usando desde afuera hacia adentro (Outside In)

Continúa leyendo “TDD – ¿De adentro hacia afuera o de fuera hacia adentro?”