Buscando estudios de caso sobre cómo TDD mejoró la calidad y / o la velocidad de desarrollo [cerrado]

En mi empresa, estoy tratando de explicar por qué deberíamos estar haciendo TDD. Actualmente, la mayoría de los desarrolladores solo hacen lo que pueden para hacer el proyecto, luego agregan pruebas unitarias después del hecho para cumplir con las métricas del gerente. Cualquier ejemplo de compañías acreditadas que hagan TDD y vean los beneficios sería muy apreciado.

Un estudio de 4 proyectos en IBM y Microsoft. Publicado en la revista Emperical Software Engineering .

Estudios empíricos muestran que el desarrollo impulsado por pruebas mejora la calidad

Un artículo publicado por primera vez en la revista Empirical Software Engineering informa: "TDD parece ser aplicable en varios dominios y puede reducir significativamente la densidad de defectos del software desarrollado sin una reducción significativa de la productividad del equipo de desarrollo". El estudio comparó 4 proyectos, en Microsoft e IBM que usaron TDD con proyectos similares que no usaron TDD ...

El documento incluye 1 estudio de caso en IBM y 3 de Microsoft. Cada uno de los estudios de caso compara dos equipos que trabajan en el mismo producto, usando los mismos lenguajes y tecnologías de desarrollo, bajo el mismo gerente de nivel superior, solo uno de los cuales usaba desarrollo basado en pruebas (TDD). Ninguno de los equipos sabía que serían parte del estudio durante sus ciclos de desarrollo. El estudio de caso de IBM siguió a los equipos que realizan el desarrollo de controladores de dispositivos. Los casos de Microsoft siguieron a equipos que trabajan en Windows, MSN y Visual Studio.

El documento describe las prácticas TDD utilizadas por los equipos como flujos de trabajo minuto a minuto, así como flujos de trabajo a nivel de tarea ...

Hay un capítulo sobre TDD con un estudio de caso en el libro reciente, "Making Software: What funciona y por qué lo creemos". Pero puede estar decepcionado, ya que si recuerdo correctamente, el estudio no descubrió ningún beneficio real para TDD. El estudio de caso fue interesante de todos modos, y el libro en general es uno de los mejores libros de software que he leído recientemente. Contiene muchos estudios de casos de cosas como programación de pares, revisión de código, etc.

Definitivamente revisa esto: TDD Probado Efectivo! ¿O es eso?

... cuando Phil Haack anunció que la investigación respalda la efectividad de TDD , estaba más que un poco interesado en ver lo que realmente contenía el informe vinculado . Phil cita del resumen.

Descubrimos que, en promedio, los estudiantes que realizaron primero los exámenes escribieron más exámenes y, a su vez, los estudiantes que escribieron más exámenes tendieron a ser más productivos. También observamos que la calidad mínima aumentó linealmente con el número de pruebas de programador, independientemente de la estrategia de desarrollo empleada.

Obviamente, Phil ha leído el resto del informe y proporciona sus piezas favoritas que parecen hacer lo que sugiere su título. Sin embargo, una de las cosas que me preocupan cuando veo cosas que respaldan las últimas y mejores prácticas de desarrollo de software es una fuerte tendencia hacia el sesgo de confirmación : buscar la confirmación de las teorías actuales y pasar por alto los contraindicadores.

Entonces, siendo del tipo curioso y dado que TDD es algo que estoy vigilando para ver si es algo que me gustaría adoptar algún día, entré en el informe ...

... sin dudas, probar primero lleva a tener más pruebas por unidad funcional. La pregunta es si esto es valioso. Este estudio parece indicar que probablemente este no sea el caso, al menos si la calidad es su ganancia prevista. Pero entonces, no me sorprende que la cantidad de pruebas no corresponda a la calidad, así como tampoco me sorprende que la cantidad de líneas de código no corresponda a la productividad.

El autor tiene muchos puntos buenos acerca de que TDD no es tan efectivo (a pesar de ser exagerado)

mire cuánto tiempo usted y el cliente pasaron probando manualmente el software; compárelo con una estimación de cuánto tiempo hubieran tomado las pruebas automatizadas al estilo TDD. Embolsar la diferencia

en mi experiencia, las pruebas automatizadas de TDD son de oro porque brindan seguro y eliminan enormes cantidades de pruebas manuales

Como señaló Andres F, puede obtener estos beneficios simplemente de las pruebas automatizadas, no necesariamente de TDD; sin embargo, TDD requiere pruebas automatizadas en lugar de ser una ocurrencia tardía o agradable de tener

Ser obligado a pensar primero en las pruebas también lo obliga a pensar en problemas relacionados con la calidad, como la modularidad, el diseño de la interfaz, etc., antes de comenzar a escribir código.

Personalmente, creo que uno de los mayores beneficios de TDD es que escribir la prueba primero mantiene la especificación de lo que el código realmente tiene que hacer fresco en tu mente mientras escribes el código, en lugar de resolverlo. -como-tu-codigo.

desea exponerlo: sugiera que lo haga para el próximo proyecto y luego aprenda de él. Si resulta que funciona muy bien para usted, entonces espero que continúe usándolo y si le tomó más tiempo hacer el proyecto y / o dedicar todo su tiempo a escribir pruebas en lugar de codificar, entonces seguramente lo descartará como un fracaso.

Creo que la solución del mundo real es (como la mayoría de las cosas) a mitad de camino, quieres pruebas pero no quieres que las pruebas sean más importantes que el proyecto.

(Personalmente, creo que TDD es una moda pasajera, suena bien en teoría, pero en la práctica ... no tan bueno. Creo que las pruebas de integración son mucho más importantes, pero ese podría ser el tipo de proyectos complejos en los que trabajo).

He estado trabajando con TDD durante 2 años y donde trabajaba en ese momento, todos estábamos reacios a usar, incluidos los gerentes. Sin embargo, pronto se convirtió en lo correcto. Los beneficios que notamos pronto fueron

• Descubriendo errores en una etapa temprana.
• Escribir un mejor código sin siquiera darse cuenta.
• Su código ahora es más fácil de mantener ya que debido a sus pruebas, todo está en pequeños trozos (teníamos funciones que eran 300-400 líneas) tonto. Ahora máximo 30 y todo probado de forma independiente.

Los gerentes no sabrían, ya que todos están interesados ​​en una cosa "¿Has terminado". Pero luego se quejan cuando el software sigue rompiéndose sin darse cuenta. Con una buena cobertura y pruebas sensatas. No es la cantidad sino la calidad lo que realmente se puede ver cuando alguien rompe una funcionalidad. Desafortunadamente, también es difícil si está solo. Tuve el mismo problema, ya que podría necesitar cambiar el código, por ejemplo, clases base, etc. para que pueda hacer que partes del software sean comprobables.

Les doy un ejemplo: quería burlarme del repositorio pero no había interfaz y necesito inyectar el repositorio en mi capa de servicio y, por lo tanto, agregar / modificar un constructor en toda la tienda, esto resultó ser un gran problema, pero en Al final tengo más de 200 pruebas solo probando un área del sistema y quedaron impresionados.

Usualmente hago lo siguiente:

• Mantengo mis pruebas de unidad muy cortas
• Solo 1 afirmación. No hay ruleta rusa.
• Pruebo un escenario positivo-negativo y de excepción

En cuanto a los estudios de casos, me temo que no estoy seguro de haber visto ninguno. Necesitas construir tu proyecto y convertirte en tu caso de estudio. También pueden quedar impresionados.

Espero que ayude