El Desarrollo Dirigido por Tests (Test Driven Development), al cual me referiré como TDD, es una técnica de diseño e implementación de software incluida dentro de la metodología XP. Coincido con Peter Provost en que el nombre es un tanto desafortunado; algo como Diseño Dirigido por Ejemplos hubiese sido quizás mas apropiado. TDD es una técnica para diseñar software que se centra en tres pilares fundamentales:
- La implementación de las funciones justas que el cliente necesita y no más.
- La minimización del número de defectos que llegan al software en fase de producción.
- La producción de software modular, altamente reutilizable y preparado para el cambio.
Cuando empezamos a leer sobre TDD creemos que se trata de una buena técnica para que nuestro código tenga una cobertura de tests muy alta, algo que siempre es deseable, pero es realmente una herramienta de diseño que convierte al programador en un "oficial de primera". O, si no les gustan las metáforas, convierte al programador en desarrollador. TDD es la respuesta a las grandes preguntas de:
¿Cómo lo hago?, ¿Por dónde empiezo?, ¿Cómo sé qué es lo que hay que implementar y lo que no?, ¿Cómo escribir un código que se pueda modificar sin romper funcionalidad existente?
No se trata de escribir pruebas a granel como locos, sino de diseñar adecuadamente según los requisitos.
Pasamos de pensar en implementar tareas, a pensar en ejemplos certeros que eliminen la ambigüedad creada por la prosa en lenguaje natural (nuestro idioma). Hasta ahora estábamos acostumbrados aquellas tareas, o los casos de uso, eran las unidades de trabajo más pequeñas sobre las que ponerse a desarrollar código. Con TDD intentamos traducir el caso de uso o tarea enXejemplos, hasta que el número de ejemplos sea suficiente como para describir la tarea sin lugar a malinterpretaciones de ningún tipo.
En otras metodologías de software, primero nos preocupamos de definir cómo va a ser nuestra arquitectura. Pensamos en las clases de infraestructura que van a homogeneizar la forma de trabajar en todos y cada uno de los casos, pensamos si vamos a usar un patrón Facade y otro Singleton y una comunicación mediante eventos, o DTOs, y una clase central que va a hacer esto y aquello... ¿Y si luego resulta que no necesitamos todo eso? ¿Cuánto vamos a tardar en darnos cuenta de ello? ¿Cuánto dinero vamos a malgastar? En TDD dejamos que la propia implementación de pequeños ejemplos, en constantes iteraciones, haga emerger la arquitectura que necesitamos usar. Ni más ni menos. No es que nos despreocupemos por completo de las características técnicas de la aplicación a priori, es decir, lógicamente tendremos que saber si el desarrollo será para un teléfono móvil, para una web o para un pc de escritorio; más que nada porque tenemos que elegir unas herramientas de desarrollo conformes a las exigencias del guión. Sin embargo, nos limitamos a escoger el framework correspondiente y a usar su arquitectura como base. Por ejemplo, si escogiésemos Django o ASP.NET MVC7, ya tendríamos definida buena parte de la base antes de empezar a escribir una sola línea de código. No es que trabajemos sin arquitectura, lógicamente, si en los requisitos está la interoperabilidad en las comunicaciones, tendremos que usar servicios web o servicios REST, lo cual ya propicia un determinado soporte. Lo que eliminamos son las arquitecturas encima de esas arquitecturas, las que intentan que todo se haga siempre igual y tal como se le ocurrió al genio de la empresa. A ser posible, esas que nos obligan a modificar siete ficheros para cambiar una cadena de texto. TDD produce una arquitectura que emerge de la no-ambigüedad de los tests automatizados, lo cual no exime de las revisiones de código entre compañeros ni de hacer preguntas a los desarrolladores más veteranos del equipo.
Las primeras páginas del libro de Kent Beck (uno de los padres de la metodología XP) dan unos argumentos muy claros y directos sobre por qué merece la pena darle unos cuantos tragos a TDD, o mejor, por qué es beneficioso convertirla en nuestra herramienta de diseño principal. Estas son algunas de las razones que da Kent junto con otras destacadas figuras de la industria:
- La calidad del software aumenta (y veremos por qué).
- Conseguimos código altamente reutilizable.
- El trabajo en equipo se hace más fácil, une a las personas. Nos permite confiar en nuestros compañeros aunque tengan menos experiencia.
- Multiplica la comunicación entre los miembros del equipo.
- Las personas encargadas de la garantía de calidad adquieren un rol más inteligente e interesante.
- Escribir el ejemplo (test) antes que el código nos obliga a escribir el mínimo de funcionalidad necesaria, evitando sobrediseñar.
- Cuando revisamos un proyecto desarrollado mediante TDD, nos damos cuenta de que los tests son la mejor documentación técnica que podemos consultar a la hora de entender qué misión cumple cada pieza del puzzle.
Personalmente, añadiría lo siguiente:
- Incrementa la productividad.
- Nos hace descubrir y afrontar más casos de uso en tiempo de diseño.
- La jornada se hace mucho más amena.
- Uno se marcha a casa con la reconfortante sensación de que el trabajo está bien hecho.
Ahora bien, como cualquier técnica, no es una varita mágica y no dará el mismo resultado a un experto arquitecto de software que a un programador junior que está empezando. Sin embargo, es útil para ambos y para todo el rango de integrantes del equipo que hay entre uno y otro.
Para el arquitecto es su mano derecha, una guía que le hace clarificar el dominio de negocio a cada test y que le permite confiar en su equipo aunque tenga menos experiencia. Frecuentemente, nos encontramos con gente muy desconfiada que mira con lupa el código de su equipo antes de que nadie pueda hacer commit al sistema de control de versiones. Esto se convierte en un cuello de botella porque hay varias personas esperando por el jefe (el arquitecto) para que dé el visto bueno y a este se le acumula el trabajo.
Ni que decir tiene que el ambiente de trabajo en estos casos no es nada bueno ni productivo. Cuando el jefe sabe que su equipo hace TDD correctamente puede confiar en ellos y en lo que diga el sistema de integración contínua y las estadísticas del repositorio de código.
Para el programador junior que no sabe por dónde va a coger al toro, o si es el toro quien le va a coger a él (o a ella), se convierte en el Pepito Grillo que le cuenta qué paso tiene que dar ahora. Y así, un paso tras otro, le guía en la implementación de la tarea que le ha sido asignada.
Cuando el equipo practica de esta manera, la comunicación fluye, la gente se vuelve más activa y la maquinaria funciona como un engranaje bien lubricado. Todos los que disfrutamos trabajando en el software llevamos dentro al personaje del buen arquitecto, entre muchos otros de nuestros personajes. La práctica que aquí se describe nos lo trae para que nos ayude y nos haga la vida más fácil.