¿Cuál es el efecto de crear pruebas unitarias durante el desarrollo sobre el tiempo de desarrollo y el tiempo dedicado a las actividades de mantenimiento?

24

Soy consultor y voy a presentar pruebas unitarias a todos los desarrolladores en el sitio de mi cliente. Mi objetivo es asegurarme de que todas las aplicaciones nuevas deben tener pruebas unitarias para todas las clases creadas.

El cliente tiene un problema con los altos costos de mantenimiento por corregir errores en sus aplicaciones existentes. Sus aplicaciones tienen una vida útil de entre 5 y 15 años en las que continuamente agregan nuevas funciones. Estoy bastante seguro de que se beneficiarán enormemente al comenzar con pruebas unitarias.

Estoy interesado en el efecto de las pruebas unitarias en el tiempo y el costo del desarrollo:

  • ¿Cuánto tiempo agregarán las pruebas unitarias de escritura como parte del proceso de desarrollo?
  • ¿Cuánto tiempo se ahorrará en actividades de mantenimiento (pruebas y depuración) al tener buenas pruebas unitarias?
jgauffin
fuente

Respuestas:

25

¿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.

Paddyslacker
fuente
Me gusta esta respuesta Agregaría que la herramienta de idioma y prueba también puede tener un gran impacto en el tiempo TDD. Para un lenguaje como C #, antes de NCRUNCH, no estaba tan entusiasmado con los beneficios de TDD. Después de ver y usar NCRUNCH. En mi opinión, la tendencia a realizar pruebas paralelas es que su código es un cambio importante en la efectividad de tales herramientas. La investigación basada en 2008 puede no reflejar las herramientas actuales y su efectividad.
phil soady