Según un estudio reciente, el uso de Test Driven Development (TDD) incrementa el tiempo de codificación en un 15-30%, y resulta en un 40-90% menos de defectos. El estudio se hizo en 4 equipos de desarrollo diferentes (1 de IBM y 3 de Microsoft). Esto confirma lo que cualquier practicante de TDD te puede decir: se gasta un poquito más de tiempo en escribir las pruebas, pero la calidad del código resultante es muy superior.
Y no es el único estudio en esta área. Hay muchos más. Bob Martin resumen varios en un post de su blog. Por otro lado, Misko Hevery pasó dos semanas hace poco haciendo un seguimiento del tiempo que lleva escribir las pruebas, y llegó a la conclusión que su equipo usaba un 10% del tiempo para escribir pruebas.
Es interesante destacar que este incremento del 15-30% se refiere a la fase de codificación. Luego, los testers encontraron un 40-90% menos de bugs. Esto es 40-90% menos bugs que necesitan arreglarse. Ahora, estos bugs que necesitan arreglararse se los encontraba en la fase de test funcional. Los números exactos varian, pero es frecuente observar que los bugs que se encuentran en esta fase requieren al menos 10 veces más de tiempo para arreglarlos que si hubieran sido encontrados al momento de desarrollo. Cuando tenemos esto en cuenta, tiene mucho sentido invertir un 15-30% de tiempo extra para escribir pruebas unitarias.
Un ejemplo concreto: el otro día me enteré de un estudio interno en una empresa que usa un enfoque más "tradicional" (léase, "cascada"). El tiempo que gastaban en cada fase era: 5 meses de análisis, 2 meses de codificación, y 7-8 meses de debug. Entonces, gastaban 4 veces más tiempo haciendo debug que escribiendo ese mismo código! ¿Qué pasaría si pudieran disminuirse esos 7-8 meses en un 40-90% (ahorrando así entre 3 y 7 meses), a costo de pasar un par de semanas escribiendo pruebas unitarias con un enfoque TDD?
Y esto ni siquiera tiene en cuenta los beneficios más importantes de TDD y Behavior Driven Development (BDD). Recuerden, TDD no es una técnica de pruebas, sino una estrategia de diseño. El código de TDD casi siempre es de más alta calidad, más flexible y facil de mantener que el mismo código desarrollado usando métodos tradicionales. Además de fomentar prácticas de diseño limpio, TDD tiene otro efecto importante en los desarrolladores: los ayuda a enfocarse en los requerimientos. Otro estudio interno mostró que un proyecto grande en Cascada implementó menos del 50% de los requerimientos documentados, y más de la mitad de los requerimientos implementados nunca fueron usados.
Otras lecciones interesantes que muestra el estudio (que de hecho refleja las mejores prácticas en el espacio de TDD) son:
- Es importante empezar con TDD desde el inicio de los proyectos
- Escribir una prueba unitaria cada vez que se necesita arreglar un bug
- Usar Integración Continua
- Fomentar las pruebas unitarias rápidas
Todos estos principios son bien conocidos por los practicantes de TDD; igualmente siempre es bueno verlos confirmados en un estudio.
Sin embargo, TDD no es mágico. A muchos desarrolladores les resulta dificil de aprender - es dificil desaprender hábitos viejos. Los menos experimentados con TDD a menudo se olvidan de la parte de refactor en el ciclo probar-codificar-refactor, lo que significa que el proceso de TDD no puede hacer su trabajo como práctica de diseño. Y además todos necesitan estar haciendo TDD, incluyendo la gestión. Es dificil (no imposible, pero si dificil) hacer TDD uno sólo cuando el resto está trabajando de la manera tradicional.
Y TDD tampoco es apropiado para todas las situaciones de desarrollo, ni es un reemplazo para la arquitectura o el diseño de alto nivel. Bob Martin escribió un excelente artículo sobre el tema.
Entonces, TDD no es la bala de plata. Pero es una práctica confirmada que funciona muy bien, en muchas situaciones. La inversión es mínima, las ganancias son enormes. Así que si todavía no hacen TDD, deberían empezar. Un buen punto de inicio es el libro Test Driven: TDD and Acceptance TDD for Java Developers de Lasse Koskela. O, en el mundo .NET, el libro Test-Driven Development in Microsoft .NET de James Newkirk y Alexei Vorontsov.
