O cómo empezar las aplicaciones por sus fallos cuando todo está controlado...
El cliente no sabe lo que quiere hasta que no lo ve. En los tiempos que corren, es normal trabajar con ciclos muy cortos de desarrollo e incorporación de mejoras. No podemos preveer todo lo que va a suceder en un proyecto desde su inicio. Por eso es clave adaptar la metodología de trabajo a requerimientos cambiantes.
Y aquí llega el Test Driven Development (TDD) es una técnica de programación con origen en la filosofía de Extreme Programming, que a su vez está relacionado con el Agile Software Development...
Si eres programador, -Yo no lo soy. Sólo en círculos reducidos-, habrás podido comprobar que cualquier desarrollo dejado a su suerte tiende a la entropía y al caos. Al comienzo, cuando el volumen de código y la funcionalidad están acotados, todo es satisfacción. Programas, refrescas y funciona... todo está bajo control.
La situación cambia cuando comienzas a desarrollar nuevas funcionalidades con sus interdependencias. En ese momento te puedes encontrar con un "Efecto Mariposa" interesante: tocas una parte del código y esto hace que falle en otro lado. A veces los errores se ven: entonces corriges. Los peores errores son los silenciosos. Esos de los que no eres consciente.
¡TDD al rescate! ¿Cómo? Comenzando por el final de la historia: el fallo. :-)
Escribe los casos de uso. Es decir, describe en palabras qué debe hacer la funcionalidad que vas a desarrollar. Por ejemplo: Juan entra en la tienda; Juan navega la categoría de libros; Juan visualiza la ficha de un libro;
Escribe el test para los casos de uso descritos. ¿En serio? Sí. No te sorprendas, que ahora viene el truco. Estás testando algo que no has programado así que vas a obtener un error. No pasa nada, es parte del proceso.
Ejecuta el test. ¿Da fallo? Sí. Vamos por buen camino.
Escribe el código: Este es "el truco". Debes escribir el código justo para que el test funcione. Si tienes clara la funcionalidad y el test está bien escrito, ya tienes gran parte del programa hecho. Sólo te queda que el test valide tu código.
Ejecuta de nuevo el test. ¿Funciona? ¿Sí? ¡Perfecto! Pero hace falta un paso más...
Refactorización. Este término define la tarea de rehacer el código de un programa sin afectar a la funcionalidad. Se trata de hacer mejor y más eficiente el código eliminando líneas innecesarias, depurando rutinas y, sobre todo, detectar duplicaciones y expulsarlas de nuestro código para siempre.
La refactorización, la creación de nuevos casos de uso, la interdependencia con otras funcionalidades puede llevarnos a cometer errores. Tener una batería de tests preparadas puede ayudarnos a controlar mejor nuestro trabajo y detectar si estamos haciendo bien las cosas. Y si la cosa crece, se agradece.
Grande, grande.
En serio, vale la pena.
El problema que tiene es que la curva de aprendizaje de Rails + la curva de aprendizaje de la parte de tests + el tiempo invertido en desarrollar primero el test es alto, muy alto, y cuesta mucho tiempo coger cierta agilidad / habilidad en cambiar el paradigma de pensamiento, pero una vez lo haces tienes cosas increíbles, como proyectos desarrollados desde cero con decenas de miles de visitas al día, miles de usuarios en menos de una semana y sin errores.
En ello me encuentro metido... y estoy seguro de que sí que vale la pena. Es como la usabilidad... la gente no entendia que era mejor comenzar por el interfaz, creían que ganaban tiempo si empezaban a programar inmediatamente.
Haciendo una analogía... mira el Madrid, va a ganar la liga hoy, cuando comenzaron con un juego mediocre... hay que entrenar para llegar entero al final... no? Todo es una lucha contra la impaciencia... ;-)