lunes, noviembre 30, 2009

Cuanto BUFD necesitamos en TDD

El viernes pasado dimos el curso de día entero que armamos sobre TDD que incluye los siguientes módulos:
  • Introducción a TDD + Ejemplos con Live Coding
  • Refactoring + Ejemplos con Live Coding
  • Test Double (dependencias, Mocks, fakes, etc) + Ejemplos con Live Coding
  • Trabajando con Legacy Code
  • Mejores prácticas de TDD
Y uno de los temas que más discutimos es el nivel de BuFD necesitamos a la hora de comenzar con TDD, y digamos que hay como dos caminos y dependen mucho de la experiencia y el conocimiento del dominio. Cuando hablamos de BuFD en TDD me refiero a cuantos test cases creamos antes de crear el SUT (System under test):
  1. una opción es bien evolutivo, creando un test cases por vez, arreglar la compilación, hacerlo green y refactor, bien chiquitito, baby steps bien TDD y evolutivo
  2. la otra opción tiende a crear más test cases antes de comenzar con el SUT, lo cual de alguna manera organiza más el trabajo y permite ver el progreso.
La opción que más me gusta a mi es la primera, ya que permite ir de a poco, haciendo funcionar solo una cosa al mismo tiempo y permite estar más concetrado y no perderse con otros temas, obviamente... pensando globalmente creo que es más que interesante al menos listar todos los test cases que tenemos en la cabeza cuando comenzamos a hacer algo, no digo codificarlos, sino listar los diferentes metodos o test (specs) que tenemos en la cabeza y dejar el método vacío, lo cual permite pasar unos minutos pensando todos los escenarios que se nos vienen a la cabeza y luego arrancar uno por uno, de esa manera uno pude tomar decisiones up front pero sigue teniendo las ventajas de baby steps.
Por otro lado, poder tener los test cases listados puede servir cuando hay que diseñoar junto a un developer más junior, lo cual lo organiza y le deja documentado su trabajo a futuro (dia/semana) y por que no pensar en medir progreso, a medida que los test cases pasan a verde, es el progreso.
En conclusión, a mi me gusta más la idea esta que les comenté recien, listar todo lo que se me viene a la cabeza y luego arrancar uno por uno, y si en el medio se me ocurre algún test más lo agrego a la cola, pero creo que tambien depende mucho de quien esté diseñando/programando y tiene que ver con que tan seguro o confidente estás con el dominio y TDD.

Algún pensamiento para compartir?

2 comentarios:

Unknown dijo...

Que tal Gustavo:
Muy bueno el artículo. Personalmente también prefiero el primer acercamiento que planteás: escribir un test y trabajar concentrado en él hasta resolverlo. Lo que encontré muy cómodo es llevar una lista de TODO, en la cual voy anotando todo lo que me viene a la mente mientras trabajo con ese test (otros tests que se me ocurre debería implementar, refactorizaciones interesantes que se pueden aplicar, conceptos del dominio que me gustaría modelar, incluso comentarios sobre cómo modelaría algo), para no distraerme. La idea es que todo lo que me puede distraer de mi test actual va al TODO, con la intención de que no me quite de vista lo que estoy haciendo ahora. Y cada vez que logro que todo pase en verde, ahí selecciono la próxima tarea a realizar, volviendo al TODO.

Me interesa mucho el punto que nombraste sobre Trabajando con Legacy Code. ¿Tenés material al respecto para recomendar?

Saludos,
Abel Armoa

Gustavo Andrés Brey dijo...

Abel,
Por supuesto... nunca escuchaste de la biblia, Working effectively with Legacy Code del gran Michael Feathers? El libro es genial, da para comprarlo. Pero tambien hay varios articulos y papers de Michael en objectmentor.com. Si no los encontrás avisame!

Saludos,