¿Qué es TDD? (Test Driven Development)

A la hora de abordar un problema, querer arreglar un bug, refinar un algoritmo o refactorizar parte del código, es importante saber cuál es el resultado que se espera al final y cuál es el estado actual. Ya sea a través de TDD o no, estos dos conceptos tienen que estar claros antes de empezar a escribir código. En caso contrario nos encontraremos perdidos, improvisando e incluso generando código que no va a servir para el objetivo en cuestión.

Teniendo controlados estos dos conceptos, vamos a adentrarnos en la filosofía TDD (Test Driven Development en inglés).

Es importante estar familiarizado con el concepto "Test" y por qué deberías empezar a hacer tests (si no los haces ya). Si para tí son conceptos nuevos te recomiendo leer primero mi anterior artículo ¿Por qué debes empezar a hacer tests?

Como su propio nombre (en inglés) indica, se trata de desarrollar guiándose por los tests. En otras palabras escribir primero el test y desarrollar después. Es un ciclo en el que se usa al test como validador para cuando se cumple con el objetivo sin ir más allá de lo necesario ni ir haciendo pruebas manuales con cada cambio que probemos.

El mantra del TDD es:

En detalle:

Primero hay que escribir el test como si la funcionalidad estuviera ya desarrollada con el resultado esperado. En este momento, al no tener nada desarrollado, el test fallará. Esto es bueno, no hay que preocuparse en este punto.

Acto seguido hay que empezar con el desarrollo pero paso a paso. La idea es desarrollar el mínimo código posible para que el test pase, aunque no sea bonito, y no escribir todo un bloque de código antes de volver a ejecutar el test.

Una vez que el test pase, hay que refinar y refactorizar el código. Este mismo test te ayuda con el proceso y que siga funcionando, como en el paso GREEN.

Un antes y un después

Básicamente actualmente desarrollamos toda la solución en nuestra cabeza y la volcamos toda en el código. Así es como se suele hacer. En cambio, con el TDD, al ser el test el que te dice cuándo es suficiente para que todo funcione, descargas gran parte de esta carga mental que conlleva desarrollar toda la solución de cabeza y escribirla. Por eso es importante ir ejecutando el test con cada pocos pasos que avancemos para asegurarnos de no escribir más código del que es estrictamente necesario, ya que, al tener bien definido el resultado esperado en el test, una vez que este pase se acabó.

Pros y contras del TDD

Por una parte tenemos los pros de por qué deberías usar TDD, tales como:

1. Descarga mental del proceso completo de desarrollo de la solución al problema.
2. No escribir más código del necesario para solucionar el problema.
3. Al ir ejecutando el test con frecuencia, depurar los errores es mucho más sencillo y metódico, ya que el test te va informando con cada ejecución y pequeño fragmento de código añadido.
4. Tienes mucha más confianza de que la solución es buena ya que tienes uno o varios tests que aseguran que se cumple con el objetivo.

Por otro lado tenemos los contras del TDD:

1. Al principio cuesta adaptar el flujo de pensamiento al hecho de empezar por el test y dejar que te guíe.
2. A veces, sobretodo al principio de usar TDD, puede dar la sensación de que la solución es demasiado simple, que de haber procedido sin TDD sería mejor.

Escenarios en los que el TDD es clave

En la práctica se podría emplear TDD en la mayoría de los casos, pero vamos a definir tres grandes grupos:

- Implementar una funcionalidad nueva

Al implementar una funcionalidad nueva, ya sea una función unitaria pura o un conjunto de funcionalidades, te ayuda a cumplir con el objetivo marcado.

- Arreglar un bug

Al querer arreglar un bug es mejor si primero estableces un test para reproducir el error y después desarrollas la solución. De esta manera no tienes que reproducir el error manualmente ni a través de un conjunto complejo de funcionalidades.

- Refactorizado

En el momento en el que decides aplicar un refactorizado sobre un bloque de código, es de vital importancia escribir primero los tests que contemplen lo que hay hasta el momento. Así con cada refactorización puedes ver si lo que ya funcionaba lo sigue haciendo. De lo contrario acabarás con un refactorizado fallido al dejar el funcionamiento peor de lo que estaba, aunque el código esté impoluto.

Conclusión

La metodología TDD tiene varios beneficios, tales como la descarga mental y la seguridad en el código desarrollado.

Por otra parte tiene inconvenientes, como por ejemplo (y el más acentuado), cambiar la manera de abordar el problema. Como hemos comentado estamos habituados a empezar a escribir código como locos cuando tenemos una idea y la desarrollamos íntegramente de cabeza o, peor, vamos improvisando.

En cualquiera de los dos casos podemos caer en el error de elaborar en exceso la solución, dar más rodeos de los necesarios y acabar con más código del necesario.

Hay varios escenarios en los que es útil el TDD: