¿Qué problema hay en utilizar TDD?
El otro día hablaba con un cliente sobre utilizar TDD en el desarrollo de sus aplicaciones, su viabilidad y su importancia comparado con una simple implementación de tests después del desarrollo?
Me parece interesante trasladar la misma reflexión a este artículo y poder comentarlo contigo. ¿Qué te parece?
Pero, antes estaría bien situarnos.
¿Qué es TDD?
Del inglés Test-driven Development (Desarrollo guiado por pruebas de software), TDD es un enfoque de desarrollo de software en que tú primero escribes los tests y después utilizas estos tests para diseñar tu aplicación y obviamente desarrollarla. Puedes leer un poco más en Wikipedia. :)
¿En qué me puede ayudar el TDD?
TDD, como una herramienta más en tu caja de herramientas, puede ayudarte a validar los tests y pruebas que tengas preparados. Si, al contrario, programas antes de los tests, tendrás que hacer la validación manualmente y ya sabemos qué pasa cuando el sistema escala.
¿Por qué no lo utilizan todos?
Creo que TDD siempre estuvo envuelto en polémica por la inclinación en la curva de aprendizaje. Para empezar requiere disciplina; pero también por los diferentes problemas y resistencias que encuentra en determinados sectores. ¿Es posible que sea de las herramientas que tengan más diferencia entre su fama y su adopción?
Pero, si es un paradigma maduro...
Más allá del debate de que el “TDD daña la arquitectura y el diseño”, siendo un paradigma con mucho potencial y con más de 15 años de mercado, ¿por qué sigue llenando “de dudas al personal”?, si utilizado (correctamente) puede ayudar a evitar problemas futuros en tu aplicación,¿ cuando esta ya esté en producción? Esto significa implementar soluciones de software más robustas, lo que quiere decir también ahorro en tiempo y dinero.
La clave puede pasar por saber cuándo utilizar TDD
De la misma forma que tienes otros enfoques y frameworks en tus equipos, creo que el mérito está en saber cuando utilizar TDD. El enfoque “code-first”, por ejemplo, también es válido.
De hecho es muy probable que estés leyendo este artículo porque estás en la situación en que el enfoque “code-first” haya ganado la partida al plan inicial de “test-first”. ¡No te deprimas¡ La mayor parte de los desarrolladores estamos acostumbrados a trabajar de esta forma; primero escribo el código y solamente después las pruebas. Los beneficios de este enfoque clásico son, entre otros, la flexibilidad - puedes rediseñar y hacer tests cuando quieres - y la velocidad de entrega.
Desde mi punto de vista los dos pueden convivir en un proyecto, pero no al mismo tiempo, o en la misma fase. Además, el enfoque “test-first” permite tener una mejor calidad de pruebas. ¿No estàs de acuerdo?
¿Cual es el problema entonces?
Pienso que hay varios problemas; Uno de ellos es que muchas veces se empieza a trabajar sobre un problema sin saber exactamente qué es lo que se está solucionando. ¿Para qué ejecutar tests si no se sabe el camino? ¿Para sentir el dolor del TDD? :) En esta situación los tests se convierten muy rápidamente en una carga con costes elevados.
Conocer el problema
Como en cualquier proceso de innovación, y si el TDD es un opción, es importante conversar con el cliente, hacerle las preguntas correctas y conocer bien el “dominio del problema”. Creo que en esta fase no hay porquè hacer tests.
Porque, para ser productivo necesitas saber qué estás desarrollando. ¿Está bien definido el producto o servicio? Estás en una fase de prototipado? ¿Por qué hacer tests en esta fase?
Los tests como parte del sistema
TDD también tiene sentido a partir del momento en que trates a los tests como una parte más de tu sistema y que estas pruebas no dañen el flujo de tu desarrollo. Para ello es importante dejar que el diseño impulse el test y no al revés. Si no, hazte la pregunta:
¿Es más importante la integridad del diseño del sistema o la posibilidad de realizar tests?
Al final del día quien haga que el TDD funcione eres tu, programador, persona que implementa, que diseña, que organiza y prueba.
¿Cuáles son los problemas más comunes que se encuentra quién quiere utilizar TDD?
Antes de finalizar esta nuestra primera reflexión sobre TDD, te dejo alguna de las excusas más utilizadas para no utilizarlo.
Tests vs QA
Es muy común escuchar, o leer que se entiende el TDD simplemente “como algo relacionado con tests” y que el desarrollador no debe hacer el trabajo de QA. Es trabajo duplicado.
Deadlines
Los deadlines y el tiempo de entrega refuerzan la idea de que el “TDD es una técnica que consume demasiado tiempo” y, ¡hay que entregar el producto en el deadline estipulado!
¿Es un tiempo, o precio que vale la pena pagar? Se trata de encontrar los bugs y errores lo antes posible, ¿no?
Mala experiencia
El pasado es muchas veces un fantasma en los proyectos de desarrollo. Aquella experiencia de utilizar TDD en un código que no está diseñado para ello, pues no está pensando en capacidad de prueba, modularidad, ni tests unitarios, puede pasar factura.
Conclusión
Concluyendo y como he comentado anteriormente, TDD es un enfoque muy famoso, por eso hay mucho material en la red, cursos y libros que puedes consultar para saber más sobre el tema. Si no, ¡pulsa en la burbuja abajo y hablamos! ;)
Si aún no utilizas el proceso TDD y te lo estás planteando, creo que será importante hacer la “reflexión de necesidades”, o sea, responder a las preguntas:
- ¿es realmente necesario ejecutar todos los tests, en toda la aplicación como parte del proceso red-green-refactor?
- ¿es para mí el TDD? ¿Es para mi equipo y se adapta a nuestros tipos de proyectos?
Es probable que algunas partes de la aplicación no necesiten tests. En este caso podrías centrar tus pruebas automáticas en código que cambia muchas veces, o en la parte más importante de la aplicación, en la lógica de negocio.
El TDD, si implementado, debería ser un proceso iterativo en que el código de producción y los tests se crean de forma alternada.
Eso sí, hay que tener en mente que “no es posible mejorar si hay mucha tendencia en recuperar viejos hábitos”.
¿Cómo es o ha sido tu experiencia y la de tus programadores con TDD?
Fuentes: