Bug Driven Development

Ayer leyendo el blog de Phil Haack me ha gustado mucho la respuesta imaginaria que le hace en su blog a un hipotético escéptico de toda metodología de testing y en la que se inventa el concepto de BDD:

I’m sorry, but I’m not a fan of Bug Driven Development. I think Test Driven Development is not without its challenges, but it’s a better alternative. Either you’re with us, or against us. Are you a bug lover? Bug Driven Development gives comfort to the bugs.

Yo no sería tan radical para decir que si no prácticas el Test Driven Development caerás en un proceso continuo de corrección de errores, pero lo que no cabe duda es que si no existe ningún proceso de calidad, si no existen unit tests, integration tests o una automatización mínima de los tests, se llega a un punto en el que el equipo de desarrollo entra en modo corrección de errores.

Quizás una de las peores consecuencias de esta BDD es que muchos de esos bugs, que no fueron testeados en su momento, ocasionarán cambios en el diseño y en la arquitectura del sistema, cambios que pueden requerir desde horas de código hasta muchos días. Y todo por no seguir un proceso de mínima prevención en un primer momento.

Al final esto de TDD y BDD no deja de recordarme en cierto modo a la medicina preventiva (TDD) y la medicina curativa (BDD).