¿Hay pruebas contundentes del ROI de las pruebas unitarias?

Question

Las pruebas de unidad me parecen geniales, pero no estoy seguro de que deba dedicarle tiempo realmente a aprenderlo a menos que pueda convencer a otros de que tiene un valor significativo. Tengo que convencer a los otros programadores y, más importante aún, a los contadores de frijoles en la administración, de que todo el tiempo extra dedicado a aprender el marco de prueba, escribir pruebas, mantenerlos actualizados, etc. se pagará solo, y algo más.

¿Qué comprobante existe? ¿Alguien realmente ha desarrollado el mismo software con dos equipos separados, uno que usa pruebas unitarias y el otro no, y comparó los resultados? Lo dudo. ¿Se supone que debo justificarlo con: "Búscalo en Internet, todo el mundo está hablando de eso, así que debe ser lo correcto"?

¿Dónde está la evidencia sólida que convencerá a los legos de que las pruebas unitarias valen la pena?

Answer 1

Sí. Este es un link a un estudio de Boby George y Laurie Williams en NCST y un another por Nagappan et al. Estoy seguro de que hay más. El Dr. Williams publications en las pruebas puede proporcionar un buen punto de partida para encontrarlas.

[EDITAR] Los dos artículos anteriores hacen referencia específicamente a TDD y muestran un aumento del 15-35% en el tiempo de desarrollo inicial después de adoptar TDD, pero una disminución del 40-90% en los defectos de prelanzamiento. Si no puede obtener las versiones de texto completo, sugiero usar Google Scholar para ver si puede encontrar una versión disponible públicamente.

Answer 2

Existen estadísticas que demuestran que corregir un error encontrado en la unidad/prueba de integración cuesta muchas veces menos que solucionarlo una vez que está en el sistema en vivo (se basan en el monitoreo de miles de proyectos de la vida real).

Edición: por ejemplo, como se ha señalado, el libro "Code Complete" estados sobre estos estudios (párrafo 20.3, "eficacia relativa de las técnicas de calidad"). Pero también hay investigación privada en el campo de la consultoría que también lo prueba.

Answer 3

Hemos demostrado con pruebas contundentes que es posible escribir software descuidado sin Pruebas unitarias. Creo que incluso hay pruebas de software horrible con Unit Testing. Pero este no es el punto.

La prueba de unidades o el desarrollo controlado por pruebas (TDD) es una técnica de diseño, no una técnica de prueba. El código que se basa en la prueba escrita se ve completamente diferente del código que no lo es.

Aunque esta no es su pregunta, me pregunto si realmente es la forma más fácil de ir por el camino y responder preguntas (y aportar pruebas que puedan ser cuestionadas por otros informes) que podrían ser cuestionadas. Incluso si encuentra pruebas contundentes para su caso, alguien más podría encontrar pruebas contundentes en su contra.

¿Es el negocio de los contadores de frijoles determinar cómo debe trabajar la gente técnica? ¿Ofrecen las herramientas más baratas en todos los casos porque creen que no necesitas las más caras?

Este argumento se gana ya sea basada en la confianza (uno de los valores fundamentales de los equipos ágiles) o perdida de potencia basado en papel del partido ganador. Incluso si los defensores de TDD ganan basándose en el poder del rol, lo consideraría perdido.

Answer 4

que adoptar un enfoque diferente a esto:

Qué seguridad tienes de que su código es correcto? O que no rompa la suposición X cuando alguien en su equipo cambia func1()? Sin pruebas unitarias que lo mantengan "honesto", no estoy seguro de que tenga mucha seguridad.

La noción de mantener las pruebas actualizadas es interesante. Las pruebas en sí mismas a menudo no tienen que cambiar. Tengo 3 veces el código de prueba en comparación con el código de producción, y el código de prueba se ha cambiado muy poco. Es, sin embargo, lo que me permite dormir bien por la noche y lo que me permite decirle al cliente que confío en que puedo implementar la funcionalidad Y sin romper el sistema.

Tal vez en el mundo académico hay pruebas, pero nunca he trabajado en cualquier parte del mundo comercial en el que cualquiera pagaría por tal prueba.Puedo decirte, sin embargo, que me ha funcionado bien, me tomé poco tiempo para acostumbrarme al marco de pruebas y la prueba de escritura me hizo realmente pensar en mis requisitos y en el diseño, mucho más de lo que lo he hecho cuando trabajaba en equipos que no escribieron pruebas.

Aquí es donde se paga por sí mismo: 1) Tiene confianza en su código y 2) Detecta problemas antes de lo que lo haría de otra manera. No tiene al tipo QA decir "hey, no se molestó en comprobar los límites -verificando la función xyz(), ¿o sí? He no encuentra ese error porque lo encontró hace un mes. Eso es bueno para él, bueno para usted, bueno para la empresa y bueno para el cliente.

Claramente esto es anecdótico, pero me ha funcionado de maravilla. No estoy seguro de poder proporcionarle hojas de cálculo, pero mi cliente está feliz y ese es el objetivo final.

Answer 5

Bueno, hay algunas grandes empresas que requieran del uso de la unidad de pruebas, pero si usted es una empresa pequeña por qué imitar los grandes?

Para mí, cuando empecé con las pruebas unitarias, hace muchos años (hoy en día usamos principalmente el modelo behavior) fue porque no podía controlar todo el camino en una sola aplicación.

Estaba acostumbrado a la primera programación inferior y una REPL así que cuando recibí la prueba de unidad (una prueba para cada función) era como traer de vuelta un REPL a lenguajes que eran muy compilados. Devolvió la diversión a cada línea de código que escribí. Me sentí dios. Me gustó. No necesité un informe para decirme que comencé a escribir mejor código más rápido. Mi jefe no necesitaba un informe para darse cuenta de que, como estábamos haciendo cosas locas, de repente nunca nos perdíamos una fecha límite. Mi jefe no necesitó un informe para darse cuenta de que el número de errores "sencillos" se reduce de (a muchos) a casi cero debido a esta cosa muy extraña de escribir código no productivo.

Como ya escribió otro cartel, no usa TDD para probar (verificar). Usted lo escribe para capturar la especificación, el comportamiento de lo que funciona su unidad (objeto, módulo, función, clase, servidor, clúster).

Hay muchas fallas e historias de éxito de cambiar a un modelo diferente de desarrollo de software en muchas empresas.

Empecé a usarlo cuando tenía algo nuevo que escribir. Hay un dicho antiguo que va un poco difícil para mí Traducir al Inglés, pero:

empezar con algo tan simple que no se dan cuenta de que lo haces. Cuando entrenes para un maratón, comienza caminando 9 metros y corre 1 metro, repite.

Answer 6

"Tengo que asesorar a los otros programadores y, más importante aún, a los contadores de frijoles en la administración, que todo el tiempo extra dedicado al aprendizaje del marco de prueba, escribir pruebas, mantenerlos actualizados, etc. se amortizará, y algo más."

¿Por qué?

¿Por qué no hacerlo, silenciosa y discretamente? No tienes que hacerlo todo de una vez. Puedes hacer esto en pedacitos.

El aprendizaje del framework requiere muy poco tiempo.

Escribir una prueba, solo una, toma muy poco tiempo.

Sin pruebas de unidades, todo lo que tiene es algo de confianza en su software. Con una prueba de unidad, aún tiene su confianza, además de la prueba de que al menos una prueba es aprobada.

Eso es todo lo que se necesita. Nadie necesita saber que lo estás haciendo. Solo hazlo.

Answer 7

Aquí hay una gran y entretenida lectura de un chico cambiando su compañía desde adentro. No está limitado a TDD. http://jamesshore.com/Change-Diary/ Tenga en cuenta que no persuadió a los "contadores de frijoles" durante bastante tiempo e hizo "tácticas de guerrilla" en su lugar.

Answer 8

Tengo un conjunto de puntos de datos para esto, de una experiencia que me vendió en pruebas unitarias.

Hace muchas lunas era un recién graduado que trabajaba en un gran proyecto VB6 y tuve la oportunidad de escribir un gran cuerpo de código de procedimiento almacenado. Del subsistema que estaba escribiendo, representaba aproximadamente 1/4 de toda la base de código, alrededor de 13,000 LOC de 50K o más.

Escribí un conjunto de pruebas unitarias para los procedimientos almacenados, pero la prueba de la unidad del código de la interfaz de usuario VB6 no es realmente factible sin herramientas como Rational Robot; al menos no fue en ese entonces.

Las estadísticas de control de calidad en la pieza eran que alrededor de 40 o 50 defectos fueron criados en todo el subsistema, de los cuales dos se originaron a partir de los procedimientos almacenados. Eso es un defecto por cada 6.500 líneas de código frente a 1 por cada 1.000-1.200 en toda la pieza. Tenga en cuenta también que aproximadamente 2/3 del código VB6 era un código repetitivo para el manejo de errores y el registro, idéntico en todos los procedimientos.

Sin demasiada mano puede atribuir al menos una mejora de orden de magnitud en las tasas de defectos a la unidad de prueba.

Answer 9

Más sobre TDD que las pruebas estrictamente unitarias, aquí hay un enlace al documento Realizing quality improvement through test driven development: results and experiences of four industrial teams, de Nagappan, E. Michael Maximilien, Thirumalesh Bhat y Laurie Williams. documento publicado por el grupo Microsoft Empirical Software Engineering and Measurement (ESM) y ya mencionado aquí.

El equipo encontrado fue que los equipos TDD produjeron código que está entre 60% y 90% mejor (en términos de densidad de defectos) que los equipos que no son TDD. Sin embargo, equipos TDD tardaron entre un 15% y un 35% más para completar sus proyectos.

Answer 10

Si también está interesado en evidencia en contra de la unidad de pruebas aquí es uno bien investigado y pensado sobre el artículo:

Why Most Unit Testing is Waste By James O Coplien (lean and agile guru)

Answer 11

Sólo para añadir más información a estas respuestas, hay dos recursos de meta-análisis que puede ayudar a encontrar la productividad & efectos sobre la calidad académica y la industria de fondo:

editores invitados Introducción: TDD-El arte de la programación sin miedo [link]

Todos los investigadores parecen estar de acuerdo en que TDD alienta un mejor enfoque de la tarea y cobertura de prueba. El solo hecho de más pruebas no necesariamente significa que la calidad del software será mejor, pero la mayor atención del programador al diseño de la prueba es alentadora. Si evaluamos como muestras de una población muy grande de posibles comportamientos , más pruebas significan una muestra más completa. En la medida en que cada prueba puede encontrar un problema importante que ninguno de los otros puede encontrar, las pruebas son útiles, especialmente si puede ejecutarlas a bajo precio.

Tabla 1. Un resumen de los estudios empíricos seleccionados de desarrollo basado en pruebas: participantes de la industria *

Tabla 2. Un resumen de los estudios empíricos seleccionados de TDD: académico participantes *

Los efectos de la Prueba-Driv en desarrollo en la calidad externa y productividad: Un meta-análisis [link]

Resumen:

Este documento proporciona un meta-análisis sistemático de 27 estudios que investigar el impacto de Test-Driven Development (TDD) en la calidad y productividad del código externo .

Los resultados indican que, en general, TDD tiene un pequeño efecto positivo en la calidad pero poco o ningún efecto perceptible en la productividad. Sin embargo, el análisis de subgrupos tiene y encontró que tanto la mejora de la calidad como la caída de la productividad son mucho mayores en los estudios industriales en comparación con los estudios académicos. Se encontró una mayor caída de productividad en los estudios donde la diferencia en el esfuerzo de prueba entre el TDD y el proceso del grupo de control fue significativa. Una mejora más grande en la calidad también fue encontrada en los estudios académicos cuando la diferencia en el esfuerzo de prueba es sustancial; sin embargo, no se pudo derivar ninguna conclusión con respecto a los estudios industriales debido a la falta de datos.

Por último, la influencia de la experiencia desarrollador y tamaño de la tarea como variables moderadoras era investigado, y una correlación positiva estadísticamente significativa fue encontrada entre tamaño de la tarea y la magnitud de la mejora en la calidad .