Hace poco en una code kata alguien me dijo, … “y qué ventajas tiene esto de hacer TDD?”. Le dije… en nuestro proyecto, actualmente con casi 25.000 lineas de código Python (multiplica x4 si piensas en Java), no hemos necesitado nunca bugtracker. Cuando ha aparecido algun bug, se ha corregido enseguida y vuelto a subir a producción. Podemos hacer una release a producción cada dos días y sólo con una persona de QA, que dedica 10 minutos antes de cada release. No llegamos al continuos deployment por falta de recursos pero estamos muy cerca.
Cuando tenemos que hacer un cambio, lo hacemos en cuestión de horas o minutos y podemos subir a producción con total garantía (98%) de no haber roto nada.
Cualquiera del equipo le puede meter mano a cualquier parte del proyecto.
Lógicamente no obtenemos estos resultados por la practica de TDD en exclusiva, sino por todas las practicas y valores de eXtreme Programming (recuerda que TDD/BDD es una parte de XP).
Y todavía podía seguir enumerando ventajas. Sin embargo, el código de nuestro proyecto no es open source, así que la gente tiene que creernos. Ahora, con pyDoubles, puedes ver los resultados tu mism@:
Resultados empíricos basados en pyDoubles:
En la última release del framework, la 1.2, hemos conseguido compatibilidad total con Hamcrest, el framework más conocido de matchers, para mejorar la legibilidad de los tests. Estratégicamente esto hace que pyDoubles pueda convertirse en un framework de referencia, ya que Hamcrest es muy popular y ahora ambos frameworks encajan perfectamente. Es un gran logro a nivel de negocio, teniendo en cuenta que queremos que pyDoubles sea usado.
¿Sabes cuanto nos ha costado a nivel de desarrollo? 3 horas de trabajo. Puedes ver los commits que se han hecho de la version 1.1 a la 1.2 si quieres mas datos objetivos. Nunca habiamos visto el código de Hamcrest ni habíamos desarrollado pyDoubles pensando en Hamcrest, sin embargo, hemos desarrollo siguiendo SOLID, dejando todo abierto a extensión y cerrado a modificación. El resultado es contundente. Apenas un poquito de esfuerzo para alcanzar un gran resultado.
¿Cuánto nos podía haber costado esto sin hacer bien TDD? Probablemente semanas de trabajo. Probablemente haber tirado medio framework y haberlo tenido que reescribir, con el riesgo de cargarnos por el camino las funcionalidades existentes.
En esta release 1.2 no solo hemos tardado poco, sino que estamos seguros de que no se ha roto ninguna funcionalidad.
¿Cuál es el orden de beneficio de esta forma de trabajar? Dificil de cuantificar pero la sensación es de ser 10 veces más productivos. Entonces ahora ¿es más caro o es más barato hacer un buen TDD/BDD?
No necesitamos convencer a nadie, los datos empíricos van demostrando las ventajas por su propio peso 🙂
Olvídate de convencer a tu entorno sobre las ventajas de XP, practica con el ejemplo.