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?

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.

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

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.

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.

Si también está interesado en la evidencia contra las pruebas unitarias, aquí hay un artículo bien investigado y pensado:

Por qué la mayoría de las pruebas unitarias son desperdicio Por James O Coplien (gurú delgado y ágil)

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.

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.

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 *

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

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.

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.

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.

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.