Loving TDD

Soy un desconfiado de las metodologías. Como todo programador, me gusta la parte en la que vamos a codear. Por supuesto, no soy un negado, muchos años de programación en proyectos de distinto tamaño me han hecho valorar algunas de las herramientas que proveen las diversas metodologías que probé, aunque tiendo a considerarlas a todas un poco hinchadas.
En estos momentos estamos probando con Scrum para gestión y TDD como normativa de programación -y otras cosas sacadas de XP-, al estilo que cuenta Henrik Kniberg en “Scrum and XP from the Trenches” (excelente lectura, la recomiendo ampliamente) y estoy teniendo mucho mejor resultado de lo que esperaba.
En particular, hoy mismo tuve que resolver dos problemas en el que usar TDD me solucionó realmente mucho más de lo que esperaba, y me permitió ser realmente ágil:
Tenia que resolver un simple proceso de login, que es un componente de prácticamente todas las aplicaciones en las que trabajamos, por lo que está bastante generalizado, en un package llamado “SmallLogin”, que en teoría debe ser reutilizado en todas las aplicaciones.
Bien, el proceso entonces sería: a) Instalar el package, b) extender las clases necesarias para efectivamente realizar el login.
-¡Hey! ¡Esto es TDD, ¿Dónde están los tests?!
Tuve que refrenar mi impulso de ir al código directamente y hacer los tests, aunque sea un simple proceso de login, así que maldiciendo por lo bajo (no me gusta “perder tiempo”), me puse a armar un test case para el login y registración de un usuario del sistema, cosa que logré luego de unos minutos (la tarea fue simplemente crear una clase con un par métodos de test).
Ahora, la tendencia natural luego de completar esta tarea sería ir browser y codear, ahora si, las clases y métodos que necesito, ¿no?
¡Error!
Esto es lo que haría si estuviera utilizando lenguajes tradicionales, pero yo estoy trabajando con smalltalk, tengo un ambiente entero a mi disposición. No hay que abrir el browser, hay que abrir el test runner y correr los tests... y programar con el debugger, que te va guiando por lo que falta para conseguir que esos tests vayan a verde.
Es el principio de “correr hacia el verde”... conseguir una versión andando lo antes posible. Hacer esto fuera de un ambiente requiere un montón de ciclos de codificación-compilación-ejecución (amén de que un programa sin un esqueleto previo simplemente no compila), pero en un ambiente se transforma en algo bastante trivial.

Momento en el que descubrí que el debugger 

es el mejor amigo del programador

El segundo “caso”, ocurrió justo después.
El sistema que tengo que hacer requiere el uso de otro de nuestros frameworks, el “Whiteboard”, que sirve para mantener un grafo de objetos compartidos entre diferentes usuarios, así que lo bajé y me puse a integrarlo con mis usuarios, y corrí los tests, que por supuesto fallaron. Siguiendo el mismo procedimiento, llegué al lugar donde estaba el error, noté que había que hacer una refactorización en el Whiteboard (no en el sistema actual), la apliqué y en menos de diez minutos tenia mis tests en verde de nuevo.
Mi gran pregunta es ¿Hubiera resuelto esto tan rápido si no hubiera hecho los tests? ¿Cuál sería la calidad del producto sin ellos? ¿Cuanto el tiempo perdido en re-works y re-tests?

En conclusión, ¡los invito a todos a disfrutar de la experiencia de hacer Test Driven Development en un ambiente vivo! (Cuidado, puede ser altamente adictivo)