TDD como metodología de diseño de software.

TDD o Test-Driven Development (desarrollo dirigido por tests) es una práctica de programación que consiste en escribir primero las pruebas (generalmente unitarias), después escribir el código fuente que pase la prueba satisfactoriamente y, por último, refactorizar el código escrito.

Con esta práctica se consigue, entre otras cosas, un código más robusto, más seguro, más mantenible y una mayor rapidez en el desarrollo.

En este post voy a centrarme solamente en cómo TDD afecta al diseño de software, si queréis más información, hay una introducción bastante buena en la Wikipedia y Carlos Blé tiene disponible online un libro muy completo. Además, en esta infografía os contamos en qué consiste TDD, en qué principios se basa (SOLID) y cuáles son sus ventajas y desventajas. Y, si quieres profundizar aún más, te recomendamos que le eches un vistazo a TDD, una metodología para gobernarlos a todos y Molecule: desarrollo TDD en Ansible.

TDD, una práctica que envuelve el desarrollo en su conjunto

Antes pensaba que TDD era una forma de programar que consistía en generar primero los tests unitarios antes que la propia aplicación, con lo que conseguías desarrollos de más calidad a costa de disminuir la productividad. Creo que es la misma idea que tiene la mayoría de la gente que conoce por encima esta práctica, pero que no se anima a utilizarla.

Sin embargo, últimamente he estado profundizando un poco en TDD y me he dado cuenta de que esto no es cierto, TDD no es para hacer pruebas, es una práctica que envuelve el desarrollo en su conjunto, especialmente el diseño de software.

De hecho, algunos dicen que su última letra, debería significar diseño y no desarrollo. Es decir, diseño orientado por las pruebas.

TDD fue creado por Kent Beck (quien también inventó Extreme Programming y JUnit), y en esencia, es un proceso a seguir, lo cual ya lo hace diferente a un simple enfoque de pruebas primero:

Este ciclo también se lo conoce como rojo (hacer que la prueba falle), verde (hacer que la prueba pase) y refactor.

Aunque al principio pueda parecer muy parecido a un enfoque de probar primero, al combinarlo con prácticas de desarrollo ágil, TDD toma un enfoque mucho más amplio, y cambia su atención de las pruebas al diseño.

TDD está mucho más relacionado con el diseño emergente que con las pruebas, de hecho, que TDD genere una gran cantidad de pruebas es un efecto secundario positivo, pero no es su propósito final.

TDD y metodologías ágiles

El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:

1. El cliente escribe su historia de usuario.
2. Se escriben junto con el cliente los criterios de aceptación de esta historia, desglosándolos mucho para simplificarlos todo lo posible.
3. Se escoge el criterio de aceptación más simple y se traduce en una prueba unitaria.
4. Se comprueba que esta prueba falla.
5. Se escribe el código que hace pasar la prueba.
6. Se ejecutan todas las pruebas automatizadas.
7. Se refactoriza y se limpia el código.
8. Se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue funcionando.
9. Volvemos al punto 3 con los criterios de aceptación que falten y repetimos el ciclo una y otra vez hasta completar nuestra aplicación.

Ejemplo práctico

Vamos con un ejemplo práctico de este ciclo:

1. Supongamos que el cliente nos pide que desarrollemos una calculadora que sume números (es lo primero que se me ha ocurrido).
2. Acordamos con el cliente que el criterio de aceptación sería que si introduces en la calculadora dos números y le das a la operación de .suma, la calculadora te muestra el resultado de la suma en la pantalla.
3. Partiendo de este criterio, comenzamos a definir el funcionamiento del algoritmo de suma y convertimos el criterio de aceptación en una prueba concreta, por ejemplo, un algoritmo que si introduces un 3 y un 5 te devuelve un 8:

public void testSuma() { assertEquals(8, Calculadora.suma(3,5)); }

Este punto es para mí el más importante del TDD y que supone un cambio de mentalidad, primero escribo cómo debe funcionar mi programa y después, una vez lo tengo claro, paso a codificarlo.

Al escribir el test estoy diseñando cómo va a funcionar el software, pienso que para cubrir la prueba voy a necesitar una clase Calculadora con una función que se llame Suma y que tenga dos parámetros.

Esta clase todavía no existe, pero cuando la cree, ya sé cómo va a funcionar. Este caso es muy trivial, pero muchas veces no sabemos exactamente qué clases hacer o qué métodos ponerle exactamente.

Es más, a menudo perdemos el tiempo haciendo métodos y clases que pensamos que luego serán útiles, cuando la cruda realidad es que muchas veces no se van a usar nunca. Con TDD sólo hacemos lo que realmente necesitamos en ese momento.

4. Por supuesto, si intentamos pasar este test nos dará un error, porque la clase Calculadora aún no existe.
5. Ahora pasamos a escribir el código de la clase, es fácil porque ya sabemos exactamente cómo se va a comportar:

public class Calculadora { public static int suma (int a, int b) { int c = a + b; return c; } }

6. Ahora ejecutamos la prueba y ya tenemos el código funcionado con la prueba pasada.
7. Una vez todo esté funcionando, pasamos a refactorizar y a eliminar código duplicado, este ejemplo es extremadamente sencillo, y en un caso real no haríamos tantos pasos para algo tan evidente, pero el código mejorado podría ser por ejemplo:

public class Calculadora { public static int suma (int a, int b) { return a+b; } }

En ejemplos más complejo, según vayamos escribiendo más test, deberíamos buscar código duplicado y agruparlo en funciones o utilizar la herencia o el polimorfismo.

8. Es importante pasar todos los test después de refactorizar por si nos hemos cargado algo.
9. Ahora deberíamos volver al punto 3 con tests más complicados y repetir el proceso, por ejemplo, podíamos pasar a que el algoritmo admita sumar números decimales, etc.

Esta forma de trabajar es también muy buena para entender el código. Sabemos que la calidad del diseño de un software está también relacionada con el conocimiento del equipo de desarrollo en relación al dominio en cuestión.

Una buena forma de practicar TDD es a través de katas, de las que podéis ver un ejemplo de resolución de la kata Mars Rover en este post.

En este sentido, las pruebas son una muy buena forma de entender el código y su funcionamiento, muchas veces incluso mejor que la documentación.

También hay que decir que no todo es perfecto en TDD, cuando llegue el momento de crear un test sobre la interfaz de la calculadora la cosa se complica. Los puntos flojos que veo en TDD son:

• Hay que utilizarlo y entenderlo bien para que sea realmente productivo, te ayuda a centrarte en lo importante y a no sobrediseñar, pero es importante saber refactorizar el código según vaya evolucionando para que sea consistente.
• Pruebas sobre interfaces gráficas. Aunque hay soluciones parciales propuestas, para mí TDD solo funciona en la capa de negocio, no encaja con interfaces visuales.
• Bases de datos. Hacer pruebas de código que trabaja con base de datos es complejo porque requiere generar unos datos conocidos antes de hacer las pruebas y verificar que el contenido de la base de datos es el esperado después de la prueba. Los objetos simulados (MockObjects) son otra opción, pero personalmente creo que se pierde tiempo con esto.