Introducción a TDD

Dentro del mundo de las metodologías ágiles tenemos varias especialidades. Una de ellas se denomina Extreme Programming, que engloba varias técnicas, siendo una de ellas Test Driven Development, TDD para los amigos. ¿En qué consiste TDD? Muy sencillo. Antes de programar una funcionalidad vamos a escribir un test unitario que pruebe esa funcionalidad que aún no está desarrollada. Recuerdo la primera vez que alguien me habló de TDD. Pensé que estaba totalmente loco. ¿Cómo voy a escribir un test sobre algo que aún no he desarrollado? ¿Cómo voy a probar algo que no existe? Ahora me doy cuenta de que en ese momento, como es normal, no entendía para qué sirve TDD. El objetivo es escribir mi funcionalidad basándome en un ejemplo (con cierta entrada espero cierta salida) y, además, construirla poco a poco, lo que se denominan baby steps.

Fases de TDD (Red, Green, Refactor)

TDD consta de 3 fases, que debemos seguir en orden. La primera, Red, consiste en programar un test que, lógicamente, no va a pasar y quedará marcado en rojo. No va a pasar ese test porque la funcionalidad aún no existe. Una vez escrito mi test desarrollo la funcionalidad de la forma más sencilla posible para pasar el test. Una vez que el test pase (Green), entro en la fase de refactorización (Refactor), en la que voy a aplicar los principios que considere oportunos para dejar mi código limpio, mantenible y funcional. Es muy importante que tras cada pequeña modificación vuelva a pasar los tests que tenga sobre esa funcionalidad para asegurarme de que no he roto nada durante la refactorización.

Por tanto, las 3 fases quedan:

  • Red: escribo mi test, y me aseguro que es un test que queda en rojo.
  • Green: escribo la funcionalidad que haga que mi test pase, es decir, se quede en verde.
  • Refactor: reescribo mi código asegurándome que el código queda bien limpio. Tras cada refactor, vuelvo a pasar los tests.
red-green-refactor
¿Cómo empiezo con TDD?

Antes de empezar a programar nada lo más recomendable es utilizar una técnica milenaria: papel y boli. Vamos a pensar en el desarrollo que tenemos por delante como un conjunto de objetos vivos en nuestro sistema que van a interactuar entre ellos. Para eso es muy recomendable leer acerca de los principios SOLID, y más concretamente del primero (la S es un acrónimo de single responsibility). El principio de responsabilidad única, o single resposibility, nos habla de que cada entidad de mi sistema debe tener una única responsabilidad. Que un objeto tenga una única responsabilidad significa que sólo debe haber una causa por la que el código de ese objeto deba ser modificado en el futuro.

Una vez que tenga un diagrama de los objetos que van a interactuar para desarrollar la nueva funcionalidad, elijo uno de ellos. El elegido va a ser el SUT (subject under test), y los demás serán colaboradores. La funcionalidad de cada SUT la programo por separado, con sus tests únicos.

¿Cómo programo con TDD?

Como he comentado, antes de comenzar a programar vamos a plantear un ejemplo de la funcionalidad que quiero diseñar. Pero no vale un ejemplo cualquiera. Comenzaremos por el más sencillo. Una vez tenga ese ejemplo plenamente funcional, voy un paso más allá y planteo otro ejemplo un poco más complicado, añadiendo un pequeño punto de complejidad. Vuelvo a repetir las 3 fases y observo posibles repeticiones de código, patrones que deba aplicar, etc. De esta forma conseguimos un código que se ciñe totalmente a una especificación (la del test), conseguimos que la arquitectura emerja de la necesidad y no de una idea prematura y, como “daño colateral”, tengo mi funcionalidad cubierta por tests automáticos. De esta forma, cada cambio que haga en el código no me obligará a pasar mil y una pruebas manuales sobre mi aplicación, y esto ahorra un montón de tiempo.

Vaya tocho…

La verdad es que todo esto sin un ejemplo es un poco tostón, y por eso en los próximos artículos vamos a desarrollar un ejemplo paso a paso con TDD. El ejemplo lo “tomaremos prestado” de 12meses12katas.com, web que cada mes plantea una kata nueva (ejercicio) y cuenta con un repositorio en GitHub donde la gente ha ido subiendo sus soluciones. Esto está genial para hacer Code Review, otra muy buena técnica para depurar nuestro estilo de programación, que nos invita a ver cómo programan los demás para aprender sus trucos, tomar sus ideas, etc. Como vemos, este es un movimiento muy colaborativo y enriquecedor.

Si quieres saber más cosas sobre Agile no dejes de seguir Codecriticon o visita mi blog personal.

¡Hasta la próxima!