¿Existe evidencia sólida del ROI de las pruebas unitarias?


127

Las pruebas unitarias me parecen geniales, pero no estoy seguro de que deba dedicar tiempo a aprenderlas a menos que pueda convencer a otros de que tiene un valor significativo. Tengo que convencer a los otros programadores y, lo que es más importante, a los contadores de frijoles en la gestión, de que todo el tiempo extra dedicado a aprender el marco de prueba, escribir pruebas, mantenerlas actualizadas, etc. se pagará por sí mismo, y algo más.

¿Qué prueba hay? ¿Alguien ha desarrollado el mismo software con dos equipos separados, uno usando 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 ello, por lo que debe ser lo correcto"?

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

Respuestas:


98

Si. Este es un enlace a un estudio realizado por Boby George y Laurie Williams en NCST y otro por Nagappan et al. Estoy seguro de que hay más. Las publicaciones del Dr. Williams sobre las pruebas pueden proporcionar un buen punto de partida para encontrarlas.

[EDITAR] Los dos documentos 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 previos a la liberación. Si no puede acceder a las versiones de texto completo, le sugiero que use Google Scholar para ver si puede encontrar una versión disponible públicamente.


14
El primer estudio compara ágil + TDD con proyectos en cascada, sus resultados serían más relevantes si hubiera comparado dos equipos ágiles. El segundo estudio menciona otros estudios que encontraron poca o ninguna bonificación de calidad para proyectos TDD. Y cuando compara las estimaciones de la administración sobre el tiempo extra necesario para TDD, se estima significativamente más alto para los dos equipos con una alta experiencia en el dominio, pero también tienen una cobertura de prueba un 20% menor. Esto confirma mi propia experiencia, creo que la seguridad es mucho más importante en sistemas con los que aún no he trabajado, mientras que las pruebas son un obstáculo para todo lo demás.
LearnCocos2D

Ninguno de los estudios compara el modelo de proceso comparable con solo el cambio de testmethofology. Es decir, pasar el tiempo utilizado en UT en realidad es mejor gastar, por ejemplo. prueba del sistema. Tal como está, también podría ser el estudio "si probamos de manera más inteligente eso ayuda".
Rune FS

1
Entonces, ¿qué pasa si el costo de corregir los errores posteriores al lanzamiento es del 0.01% del desarrollo total? TDD sería una inversión terrible en ese caso. ¿Y si los errores son pocos? Estos% s no significan nada sin contexto. Para ser justos, aún no he leído todo el estudio. Pero tal como está, su publicación es útil (buenos enlaces) pero no responde a la pregunta sobre ROI, IMO.
Instine

1
@Instine Afortunadamente (?) Hay buena evidencia de que este no es el caso. La corrección de errores posteriores al lanzamiento es exponencialmente más costosa que los errores encontrados al principio del desarrollo (que es lo que hace TDD). En ese contexto, parece poco probable un costo del 0.01% del desarrollo total para todos los errores posteriores al lanzamiento. (Para obtener más información, consulte Code Complete , en particular Boehm & al. , “Comprender y controlar los costos del software”, IEEE Trans Softw Eng (1988)).
Konrad Rudolph el

Probablemente valga la pena señalar que el primer estudio tiene un tamaño de muestra de 24 programadores (trabajando en parejas, por lo que 12 equipos). No estoy seguro de cuál sería un tamaño de muestra estadísticamente válido, pero estos parecen bajos. Quizás alguien más lo sabe?
Zachary Yates

29

"Tengo que convencer a los otros programadores y, lo que es más importante, a los contadores de frijoles en la gestión, de que todo el tiempo extra dedicado a aprender el marco de pruebas, escribir pruebas, mantenerlos actualizados, etc. se pagará por sí mismo, y algo más. "

¿Por qué?

¿Por qué no hacerlo, en silencio y discretamente? No tienes que hacerlo todo de una vez. Puedes hacer esto en pequeños pedazos.

El aprendizaje del marco lleva muy poco tiempo.

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

Sin pruebas unitarias, todo lo que tiene es cierta 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 pasa.

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


9
Los contadores de frijoles no podían distinguir una prueba unitaria del resto del código si sus vidas dependían de ello. Apoyo la sugerencia de simplemente hacerlo. Sin embargo, hay una advertencia: si no está solo, necesita que sus colegas desarrolladores adopten esta práctica. De lo contrario, interrumpirán involuntariamente sus pruebas.
Thomas Eyde

Solo hazlo y no les digas, y vende la idea a tus universidades en el coffee break ;-)
Johan

3
¿Porque te despedirían cuando no cumplieras tus plazos?
Andrew

3
@Neko: Las pruebas unitarias no agregan un "poco de sobrecarga". Que reducen la carga de trabajo mediante la prevención de toda una avalancha de errores tontos. El trabajo no crece; simplemente cambia de naturaleza de código incorrecto a buenas pruebas unitarias y buen código.
S.Lott

1
Los contadores de frijoles quieren que sus ingenieros brinden soluciones sólidas a los problemas del dominio. Simplemente puede escribir pruebas como parte de su solución. Ni siquiera se darán cuenta. Si le preguntan, puede decirles que está empleando más tiempo para asegurarse de que sea robusto y que no requiera reelaboración. Si SUGIERES que les escribas pruebas unitarias, estás pidiendo su aprobación sobre algo de lo que no saben nada.
Yorkshireman

16

Tomo un enfoque diferente a esto:

¿Qué seguridad tiene de que su código es correcto? ¿O que no rompe 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í no suelen tener 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 ha cambiado muy poco. Sin embargo, es lo que me permite dormir bien por la noche y lo que me permite decirle al cliente que tengo confianza en que puedo implementar la funcionalidad Y sin romper el sistema.

Quizás en la academia hay evidencia, pero nunca he trabajado en ningún lugar del mundo comercial donde alguien pagaría por tal prueba. Sin embargo, puedo decirle que ha funcionado bien para mí, me tomó poco tiempo acostumbrarme al marco de prueba y la prueba de escritura me hizo pensar realmente en mis requisitos y el diseño, mucho más de lo que lo hice cuando trabajaba en equipos que No escribió pruebas.

Aquí es donde se paga solo: 1) Confía en su código y 2) Captura los problemas antes de lo que lo haría de otra manera. No tienes al tipo de control de calidad que dice "oye, no te molestaste en verificar los límites de la función xyz (), ¿verdad? No puede encontrar ese error porque lo encontraste hace un mes. Eso es bueno para él, bueno para ti, 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á contento y ese es el objetivo final.


Mi tipo de control de calidad era bastante inteligente, pero no estaba mirando el código, pero era fácil decir que los límites no estaban marcados.
itsmatt

Totalmente acordado de las pruebas unitarias te obliga a pensar más en su diseño y corrección en lugar de código imprudentemente
chakrit

77
Los clientes no nos pagan para escribir pruebas. Por otra parte, tampoco nos pagan para escribir código. Nos pagan para resolver sus problemas, y cuando se enfrentan, apuesto a que también quieren que los problemas se resuelvan. Dada la evidencia, es increíble que los clientes no quieran asegurar su inversión.
Thomas Eyde

10

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

Las pruebas unitarias o el desarrollo impulsado por pruebas (TDD) es una técnica de diseño, no una técnica de prueba. El código que se escribe por prueba 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 seguir el camino y responder preguntas (y aportar evidencia que podría ser cuestionada por otros informes) que podrían formularse incorrectamente. Incluso si encuentra pruebas contundentes para su caso, alguien más podría encontrar pruebas contundentes en contra.

¿Es asunto de los contadores de frijoles determinar cómo deberían trabajar los técnicos? ¿Están proporcionando las herramientas más baratas en todos los casos porque creen que no necesita las más caras?

Este argumento se gana en función de la confianza (uno de los valores fundamentales de los equipos ágiles) o se pierde en función del poder de rol de la parte ganadora. Incluso si los defensores de TDD ganan en función del poder del papel, lo consideraría perdido.


13
escuchar, escuchar :) Mucha de la evidencia contundente para TDD también proviene de equipos muy experimentados que ya estaban obteniendo buenos resultados sin ella. TDD simplemente mejoró sus resultados en lugar de crearlos de la nada. El verdadero ROI es contratar codificadores decentes y dejarlos decidir cómo hacer las cosas.
workmad3

"¿Es asunto de los contadores de frijoles determinar cómo deberían trabajar las personas técnicas?" -> todas las decisiones comerciales se reducen a dinero. Aún así, buena respuesta, +1
jcollum

@jcollum, pero la forma en que realiza su trabajo no tiene nada que ver con el dinero y si desea que uno de los domadores rinda cuentas, déjelos decidir CÓMO hacen lo QUE les pidió
Rune FS

TDD no es una técnica de diseño, es solo una técnica de codificación. blog.ploeh.dk/2010/12/22/TheTDDApostate Muchos comentaristas no están de acuerdo en que TDD implica refactorización (que es una técnica de diseño) pero la refactorización no implica TDD. Uno puede refactorizar sin pruebas, la refactorización compleja grande afecta las pruebas unitarias de todos modos, es decir, las pruebas también deben ser refactorizadas para que también puedan volverse inválidas / falso verde; Las refactorizaciones más simples pueden no afectar las pruebas, pero el riesgo de error es menor, porque la refactorización es simple.
KolA

@KolA bueno, con el reflejo de 10.5 años después de esta respuesta, podría expresarlo un poco más a la defensiva hoy, pero aún así: no argumento que TDD es la única técnica de diseño que necesitarás y Mark comienza con eso. Una buena técnica de diseño antes de concluir que no es una. Debilitaría su opinión y diría que no debe ser la única técnica de diseño. Cada código que he escrito TDD se ve diferente del código sin el que he escrito. Yo llamaría a eso un resultado del diseño. Trabajo mejor con pizarras, debates y otras herramientas, además de TDD. Pero gracias por el enlace
Olaf Kock


6

Más sobre TDD que las pruebas estrictamente unitarias, aquí hay un enlace a la Realización de la mejora de la calidad a través del desarrollo impulsado por pruebas: resultados y experiencias de cuatro equipos industriales , por Nagappan, E. Michael Maximilien, Thirumalesh Bhat y Laurie Williams. documento publicado por el grupo de Ingeniería y Medición de Software (ESM) de Microsoft Empirical y ya mencionado aquí.

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


5

Aquí hay una lectura genial y entretenida de un tipo que cambia su compañía desde adentro. No se limita 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.


el enlace se ve interesante ... vale la pena mirar re: organizaciones cambiantes procesos funcionan ...
desagradable pastosa

5

Solo para agregar más información a estas respuestas, hay dos recursos de metanálisis que pueden ayudar a determinar los efectos de productividad y calidad en los antecedentes académicos y de la industria:

Introducción de los editores invitados: TDD: el arte de la programación sin miedo [ enlace ]

Todos los investigadores parecen estar de acuerdo en que TDD fomenta un mejor enfoque de tareas y cobertura de pruebas. El mero hecho de más pruebas no significa necesariamente que la calidad del software será mejor, pero la mayor atención del programador al diseño de las pruebas es alentadora. Si vemos las pruebas como una muestra de una población muy grande de comportamientos potenciales, más pruebas significan una muestra más exhaustiva. 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 costo.

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

https://www.computer.org/cms/Computer.org/dl/mags/so/2007/03/figures/s3024t1.gif

Tabla 2. Resumen de estudios empíricos seleccionados de TDD: participantes académicos *

ingrese la descripción de la imagen aquí

Los efectos del desarrollo basado en pruebas en la calidad y productividad externas: un metaanálisis [ enlace ]

Resumen:

Este documento proporciona un metanálisis sistemático de 27 estudios que investigan el impacto del desarrollo impulsado por pruebas (TDD) en la calidad y productividad del código externo.

Los resultados indican que, en general, el TDD tiene un pequeño efecto positivo sobre la calidad pero poco o ningún efecto discernible sobre la productividad. Sin embargo, el análisis de subgrupos ha encontrado 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 la productividad en los estudios donde la diferencia en el esfuerzo de prueba entre el TDD y el proceso del grupo de control fue significativa. También se encontró una mejora mayor en la calidad en los estudios académicos cuando la diferencia en el esfuerzo de la prueba es sustancial; sin embargo, no se pudo llegar a una conclusión con respecto a los estudios industriales debido a la falta de datos.

Finalmente, se investigó la influencia de la experiencia del desarrollador y el tamaño de la tarea como variables moderadoras, y se encontró una correlación positiva estadísticamente significativa entre el tamaño de la tarea y la magnitud de la mejora en la calidad.


4

Bueno, hay algunas compañías grandes que requieren que utilices pruebas unitarias, pero si eres una compañía pequeña, ¿por qué imitar a las grandes?

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

Estaba acostumbrado a la primera programación de fondo y un REPL, así que cuando obtuve la Prueba de unidad (Una prueba para cada función) fue como devolver un REPL a idiomas que se compilaron mucho. Devolvió la diversión a cada línea de código que escribí. Me sentí dios. Me gustó. No necesitaba un informe que me dijera que comencé a escribir mejor código más rápido. Mi jefe no necesitaba un informe para darse cuenta de que porque estábamos haciendo cosas locas, de repente nunca perdimos una fecha límite. Mi jefe no necesitaba un informe para notar que el número de errores "simples" se redujo de (a muchos) a casi nulo debido a esta cosa muy extraña de escribir código no productivo.

Como ya escribió otro póster, no utiliza TDD para probar (verificar). 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 cada vez que tenía algo nuevo que escribir. Hay un viejo dicho que me cuesta un poco traducir al inglés, pero:

Comience con algo tan simple que no se dé cuenta de que lo hace. Al entrenar para un maratón, comience caminando 9 metros y corra 1 metro, repita.


Entonces, ¿debería hacerlo? Está garantizado que funciona, y no importa si nadie más lo hace conmigo.
cuervo

En realidad, esta es una prueba de Joel: joelonsoftware.com/articles/fog0000000043.html . Me parece que puede tener más problemas que la falta del Premio Nobel de Estudio de Prueba de Unidad
Jonke

4

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

Editar : por ejemplo, como se señaló, el libro " Code Complete " informa sobre dichos estudios (párrafo 20.3, "Efectividad relativa de las técnicas de calidad"). Pero también existe una investigación privada en el campo de la consultoría que también lo demuestra.


1
Esto está cubierto en el Código completo de Steve McConnell , que es un libro que probablemente quiera tener en su estantería por otras razones.
Robert Rossney

Eso no está relacionado con el método de prueba, sino con cuándo se informa un error en el proceso y, además, sería mejor dedicar el tiempo a encontrar errores en las especificaciones, ya que el costo de corregirlos al encontrarlos durante el desarrollo se informa hasta 1000 veces más caro (un factor de 10 por fase de desarrollo)
Rune FS

OTOH, si solo soluciona los problemas que las personas realmente encuentran en situaciones de la vida real, probablemente terminen teniendo que solucionar muchos menos errores. Tampoco está claro para mí que corregir los errores antes sea realmente más barato, ya que detectar un error en una especificación puede requerir mucho más esfuerzo que detectar el mismo error en la implementación, y detectar el error es parte del costo de la corrección del error. Esta es una de estas cosas que todos creen porque suena evidente, pero nunca he visto un estudio de sonido que muestre el efecto.
LKM

0

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, constituía aproximadamente 1/4 de toda la base de código, alrededor de 13,000 LOC de 50K más o menos.

Escribí un conjunto de pruebas unitarias para los procedimientos almacenados, pero el código UB VB6 de prueba unitaria no es realmente factible sin herramientas como Rational Robot; al menos no era en ese entonces.

Las estadísticas de QA en la pieza fueron que se plantearon alrededor de 40 o 50 defectos en todo el subsistema, de los cuales dos se originaron a partir de los procedimientos almacenados. Ese es un defecto por cada 6,500 líneas de código frente a 1 por cada 1,000-1,200 más o menos 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 y registro de errores, idéntico en todos los procedimientos.

Sin agitar demasiado las manos, puede atribuir al menos una mejora de orden de magnitud en las tasas de defectos a la prueba de la unidad.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.