unit-testing - test - pruebas unitarias visual studio
¿Hay pruebas contundentes del ROI de las pruebas unitarias? (11)
Las pruebas de unidad me parecen estupendas, pero no estoy seguro de que deba dedicarle tiempo realmente a aprender 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é prueba hay? ¿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 contundente que convencerá a los legos de que las pruebas unitarias valen la pena?
"Tengo que capacitar a los otros programadores y, lo que es más importante, a los contadores de frijoles en la gestión, que todo el tiempo extra dedicado a aprender el marco de prueba, escribir pruebas, mantenerlos actualizados, etc. se pagará solo, y algo más. "
¿Por qué?
¿Por qué no solo hacerlo, silenciosa y discretamente? No tienes que hacerlo todo de una vez. Puedes hacer esto en pedacitos.
El aprendizaje marco requiere muy poco tiempo.
Escribir una prueba, solo una, toma muy poco tiempo.
Sin pruebas unitarias, 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.
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.
Bueno, hay algunas grandes compañías que requieren que uses pruebas unitarias, pero si eres una empresa pequeña, ¿por qué imitar a las grandes?
Para mí, cuando comencé con las pruebas unitarias, hace muchos años (hoy en día usamos principalmente el modelo de behavior ) fue porque no podía controlar todo el camino en una sola aplicación.
Estaba acostumbrado a la primera programación inferior y a REPL, así que cuando obtuve Test Unit (One Test for Every Function) fue como traer de vuelta un REPL a los idiomas que compilaban mucho. Devolvió la diversión a cada línea de código que escribí. Me sentí dios. Me gustó. No necesitaba 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 un plazo. Mi jefe no necesitó un informe para darse cuenta de que la cantidad 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 póster, 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 compañías.
Empecé a usarlo cada vez que tenía algo nuevo para escribir. Hay un viejo dicho que me cuesta un poco traducir al inglés pero:
Comienza con algo tan simple que no notes que lo haces. Cuando entrenes para un maratón, comienza caminando 9 metros y corre 1 metro, repite.
Hay estadísticas que demuestran que corregir un error encontrado en la unidad / prueba de integración cuesta muchas veces menos que arreglarlo una vez que está en el sistema en vivo (se basan en monitorear miles de proyectos de la vida real).
Edición : por ejemplo, como se señaló, el libro " Código completo " informa sobre dichos 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.
Hemos demostrado con pruebas contundentes que es posible escribir software malo sin Pruebas Unitarias. Creo que incluso hay pruebas de software horrible con Unit Testing. Pero este no es el punto.
La prueba unitaria o el desarrollo impulsado por prueba (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 presentar pruebas que puedan ser cuestionadas 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 su contra.
¿Es el negocio de los contadores de frijoles determinar cómo deben trabajar los técnicos? ¿Ofrecen las herramientas más baratas en todos los casos porque creen que no necesitas las más caras?
Este argumento se gana con base en 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 basándose en el poder del rol, lo consideraría perdido.
Más sobre TDD que las pruebas estrictamente unitarias, aquí hay un enlace a Realizing quality improvement through test driven development: resultados y experiencias del trabajo de cuatro equipos industriales , por 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 encontró que los equipos de TDD producían 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 un 15% y un 35% más para completar sus proyectos.
Sí. Este es un link a un estudio de Boby George y Laurie Williams en NCST y another de Nagappan et al. Estoy seguro de que hay más. Las publications Dr. Williams sobre las pruebas pueden proporcionar un buen punto de partida para encontrarlas.
[EDITAR] Los dos artículos anteriores hacen referencia específica 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 defectos previos a la liberación. Si no puede obtener las versiones de texto completo, le sugiero usar Google Scholar para ver si puede encontrar una versión disponible públicamente.
Si también le interesan las pruebas contra las pruebas unitarias, aquí hay un artículo bien investigado y pensado:
Por qué la mayoría de las pruebas unitarias son basura Por James O Coplien (gurú ágil y ágil)
Solo para agregar más información a estas respuestas, hay dos recursos de metaanálisis que pueden ayudar a determinar la productividad y los efectos de calidad en los antecedentes académicos y de la industria:
Introducción de los editores invitados: TDD: el arte de la programación audaz [ link ]
Todos los investigadores parecen estar de acuerdo en que TDD alienta un mejor enfoque de la tarea y la cobertura de la 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 vemos las pruebas como muestras de una población muy grande de comportamientos potenciales, 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 de forma económica.
Tabla 1. Un resumen de estudios empíricos seleccionados del desarrollo basado en pruebas: participantes de la industria *
Tabla 2. Un resumen de estudios empíricos seleccionados de TDD: participantes académicos *
Los efectos del desarrollo basado en pruebas sobre la calidad externa y la productividad: un metaanálisis [ link ]
Abstracto:
Este documento proporciona un metanálisis sistemático de 27 estudios que investigan el impacto del desarrollo basado en pruebas (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 discernible en 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 mayor mejora en la calidad 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.
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.
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 el código UI de prueba de unidad VB6 no es realmente factible sin herramientas como Rational Robot; al menos no fue en ese entonces.
Las estadísticas de QA en la pieza fueron que se generaron alrededor de 40 o 50 defectos 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 vs. 1 por 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 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 prueba de la unidad.
Tomo un enfoque diferente a esto:
¿Qué seguridad tiene 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 idea 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 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.
Quizás en la academia hay evidencia, pero nunca he trabajado en ningún lugar del mundo comercial donde alguien pague por tal prueba. Puedo decirles, sin embargo, que me funcionó, me tomé poco tiempo para acostumbrarme al marco de pruebas y la prueba de escritura me hizo pensar realmente en mis requisitos y en el diseño, mucho más de lo que lo hacía cuando trabajaba en equipos que no escribió 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 tienes al tipo QA que diga "hey, no te molestaste en los límites, verificando la función xyz (), ¿verdad? No encuentra ese error porque lo encontraste hace un mes. Eso es bueno para él, bueno para ti, bueno para la compañía 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.