Tienes los dedos ardiendo. Te acaban de dar un ejercicio que resolver. El ansia recorre tus venas. Tu cerebro se dispara y visualiza las tropecientas líneas de código que van a quemar tu editor de texto.
STOP!
Esa es la lección que he aprendido esta última semana en clase. A parar el carro y establecer un plan de ataque antes de lanzarte a picar código como si no hubiera mañana.
Bueno. Seamos honestos. Yo no soy de lanzarme así como así a crear las cosas. Me lo pienso un poco siempre, porque ya me voy quedando con cómo funcionan las cosas por estos lares en los que al más mínimo cambio se te cae abajo el chiringuito. Así que cojo mi cuadernito y le doy un par de vueltas antes de empezar, por si acaso.
Pero el caso es que esta semana me han enseñado una forma más metódica de atacar una nueva funcionalidad de forma controlada, reflexiva y que ayude a hacer un código bonito y mantenible (ay, cómo se te llena la boca cuando dices estas cosas).
Con todos ustedes, el Test Driven Development. O TDD para los amigos.
El proceso
- Escribir un test con el caso de comportamiento mínimo.
- Sin escribir todavía código, poner en marcha el test. Tiene que fallar. Si no falla es que no estás testeando nada.
- Escribir código suficiente (y mínimo) para pasar el test.
- Refactorizar el código si es posible.
Así hasta que no se te ocurran más tests que fallen.
Vaya rollo. ¿Verdad?
¿Por qué hacer TDD?
Pues para que funcione todo en condiciones y saber cuando rompes las cosas. ¡Obvio!
La meta del TDD es escribir código limpio que funcione. Pero hay algo más...
El ponerte a escribir tests antes que el código es más un acto de diseño y de documentación que de verificación.
Si piensas antes de escribir código, estás obligado a plantearte cómo funcionará el programa o la funcionalidad que quieres desarrollar. Tendrás que pensar en cómo llamar cada clase y sus funciones. No te quedará otra que saber qué quieres que haga exactamente, junto con aquello que recibirá y lo que sacará para integrarse en programas más complejos.
Además, el escribir tests descriptivos es una forma perfecta de documentación. Uno de los ejercicios que hemos hecho en clase nos demostró que una serie de tests bien hechos puede servir a aquel que llegue a tu programa para entender su funcionamiento.
Personalmente me ha parecido una forma de trabajar muy interesante. Deliberadamente lenta. Una herramienta muy útil para alguien como yo, que estoy empezando en este mundo de la programación y que todavía no sé muy bien qué estoy buscando antes de lanzarme a escribir.