¿El TDD realmente ralentiza mi proceso de desarrollo?
El desarrollo de software es un mundo lleno de metodologías y enfoques, pero pocos han generado tanto debate como el Test Driven Development (TDD). ..
En julio tuve la oportunidad de dar una charla junto a nuestro partner Skills Matter, dentro de la serie de Meetups Thursday’s Matters.
Durante la sesión, presenté varios ejercicios. Algunos eran intencionadamente simples, aburridos o repetitivos. Mi objetivo era crear esa sensación de repetición para que las personas hicieran la conexión con las prácticas habituales en entrenamientos de TDD (Test-Driven Development), especialmente para quienes están comenzando. Después de toda esa repetición, mostré una solución alternativa: usando TDD pero con un enfoque más "inteligente". ¿Cuánto más inteligente? Bueno, no tanto, ya que es una formalización que Uncle Bob presentó hace tiempo, pero sí lo suficientemente eficaz para orientarnos hacia soluciones más genéricas desarrolladas con TDD.
¿Cómo surgió esta idea?
Todo empezó unos meses antes, cuando me pidieron que impartiera una formación en TDD. Como muchos practicantes de TDD, pensé que ya conocía todo lo necesario, pero al preparar las sesiones, me di cuenta de que había temas que, al menos formalmente, no dominaba. Uno de ellos era el Transformation Priority Premise (TPP).
¿Qué es el Transformation Priority Premise?
El concepto es sencillo. Uncle Bob presentó una serie de transformaciones (cambios en el código para hacer que una prueba falle y luego pase, a diferencia de las refactorizaciones) que se pueden aplicar de forma casi "algorítmica".
La premisa dice que cuando tengas que decidir qué prueba escribir a continuación, elige la que te permita resolverla aplicando la transformación con mayor prioridad posible. Este enfoque te ayuda a mejorar la solución y a desarrollar un código más genérico de manera progresiva. Puede parecer simple, pero hay que ponerlo en práctica para comprender su valor.
Las transformaciones sugeridas por Uncle Bob son:
- ({} → nil) De no tener código a escribir código que utiliza nil.
- (nil → constante)
- (constante → constante más compleja)
- (constante → variable) Sustituir una constante por una variable o argumento.
- (sentencia → más sentencias) Agregar más instrucciones incondicionales
- (incondicional → if) Dividir el flujo de ejecución.
- (variable → array)
- (array → contenedor)
- (sentencia → recursión)
- (if → while)
- (expresión → función) Sustituir una expresión por una función o algoritmo.
- (variable → asignación) Cambiar el valor de una variable.
Aprendiendo con la kata de números romanos
En ese momento comencé a leer y resolver, repetidamente, la famosa kata de números romanos, un ejercicio bastante simple pero muy útil. También leí el blog Applying Transformation Priority Premise to Roman Numerals Kata hasta que todo empezó a tener sentido. Este es justamente el propósito de practicar una kata: desarrollar una memoria muscular, pero aplicada al código.
La experiencia en la formación
Practicar TDD por primera vez no es fácil, especialmente cuando las personas llegan con ideas preconcebidas y conocimientos previos. Algunos no ven la utilidad de escribir pruebas primero porque "ya saben lo que hacen". A veces basta con hablarles de "pequeños pasos" o "refactorizar cuando haya duplicación" para captar su interés.
Durante la formación, al trabajar en pareja y guiar a otros en el tema del TPP, noté que, aunque hay un orden de transformaciones sugerido (aunque, como dice el propio Uncle Bob, probablemente sea imperfecto), es posible saltar a otras transformaciones antes, siempre que intentemos aplicar la de mayor prioridad disponible.
Al final del proceso, tuve la oportunidad de trabajar con otro compañero, Mark Gray, quien propuso algunos movimientos más orientados a la programación funcional. El resultado que obtuvimos fue muy similar al que mostré durante el taller, pero diferente al que Pedro presentó en su post.
Preguntas y aprendizajes
Una de las preguntas que surgió durante el taller fue por qué decidí usar recursión. La respuesta no es simple, pero en resumen, fue el resultado de resolver esta kata muchas veces. Como en las artes marciales, la práctica constante convierte los movimientos en reflejos. Lo mismo pasa en programación: repetir esta kata me permitió detectar mejoras, aplicar mejores transformaciones y generalizar antes, siempre evolucionando el código paso a paso, sin cambios bruscos entre commits.
Si te interesa ver el workshop entero, aquí te compartimos el link al vídeo:
