¿Hay estadísticas disponibles sobre cuánto tiempo llevará desarrollar aplicaciones al crear pruebas unitarias durante el desarrollo en comparación con la codificación?
Hay algunas investigaciones muy interesantes sobre esto. Lea el siguiente documento técnico:
Realizando mejoras de calidad a través del desarrollo basado en pruebas: resultados y experiencias de cuatro equipos industriales
El documento técnico y otras investigaciones de uno de sus autores, Nachi Nagappan , se analizan aquí:
http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx
El estudio y sus resultados se publicaron en un documento titulado Realización de la mejora de la calidad a través del desarrollo basado en pruebas: resultados y experiencias de cuatro equipos industriales, por Nagappan y sus colegas de investigación E. Michael Maximilien del Centro de Investigación IBM Almaden; Thirumalesh Bhat, director principal de desarrollo de software en Microsoft; y Laurie Williams de la Universidad Estatal de Carolina del Norte. Lo que descubrió el equipo de investigación fue que los equipos TDD produjeron un código que era 60 a 90 por ciento mejor en términos de densidad de defectos que los equipos que no son TDD. También descubrieron que los equipos de TDD tardaron más en completar sus proyectos: 15 a 35 por ciento más.
"En un ciclo de desarrollo de 12 meses, el 35 por ciento son otros cuatro meses, lo cual es enorme", dice Nagappan. “Sin embargo, la compensación es que reduce significativamente los costos de mantenimiento posteriores al lanzamiento, ya que la calidad del código es mucho mejor. Una vez más, estas son decisiones que los gerentes deben tomar: ¿dónde deberían recibir el golpe? Pero ahora, en realidad tienen datos cuantificados para tomar esas decisiones ".
Además, Jason Gorman ha propuesto un experimento de este tipo para la conferencia Software Craftsmanship de este año. Ha estado probando un experimento creando la misma aplicación usando un enfoque TDD y un enfoque que no es TDD y recientemente escribió en un blog sobre sus resultados :
En 3 iteraciones, el tiempo promedio que se tardó en completar el kata sin TDD fue de 28 m 40 s. El tiempo promedio con TDD fue de 25 m 27 s. Sin TDD, en promedio hice 5.7 pases (entregándolos en pruebas de aceptación). Con TDD, en promedio hice 1.3 pases (en dos intentos, pasaron la primera vez, en uno solo tomó 2 pases).
Ahora, este fue un experimento de bebé, por supuesto. Y no exactamente condiciones de laboratorio. Pero noto un par de cosas interesantes, de todos modos.
Será interesante ver los resultados completos de este experimento cuando más personas lo realicen.
¿Hay alguna estadística disponible que muestre cuántas horas disminuye el mantenimiento cuando se realizan pruebas de unidad (buenas)?
Del documento técnico anterior:
Los resultados de los estudios de caso indican que la densidad de defectos previos al lanzamiento de los cuatro productos disminuyó entre 40% y 90% en relación con proyectos similares que no utilizaron la práctica TDD.
