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 realizar el proyecto, luego agregan pruebas unitarias después del hecho para cumplir con las métricas del gerente. Cualquier ejemplo de compañías con buena reputación que hagan TDD y vean los beneficios serán muy apreciados.
Un estudio de 4 proyectos en IBM y Microsoft. Publicado en la revista Emperical Software Engineering .
Estudios empíricos muestran que el desarrollo guiado por pruebas mejora la calidad
Un artículo publicado por primera vez en los informes de la revista Empirical Software Engineering: "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 administrador de nivel superior, solo uno de los cuales estaba usando desarrollo dirigido por pruebas (TDD). Ninguno de los equipos sabía que serían parte del estudio durante sus ciclos de desarrollo. El caso de estudio de IBM siguió a los equipos que realizaban el desarrollo de controladores de dispositivos. Los casos de Microsoft siguieron a los equipos que trabajan en Windows, MSN y Visual Studio.
El documento describe las prácticas de TDD utilizadas por los equipos como flujos de trabajo minuto a minuto, así como flujos de trabajo de nivel de tarea ...
Hay un capítulo sobre TDD con un estudio de caso en el libro reciente, "Cómo hacer software: qué 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 caso de cosas como programación de pares, revisión de código, etc.
Definitivamente echa un vistazo a esto: TDD probado ¡Eficaz! ¿O es?
... cuando Phil Haack anunció que Research Supports the Eficacia de TDD Estaba más que un poco interesado en ver qué informe en realidad contenida. Phil cita del resumen.
Encontramos que, en promedio, los estudiantes que realizaron las pruebas primero escribieron más pruebas y, a su vez, los estudiantes que escribieron más pruebas 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.
Es obvio que Phil ha leído el resto del informe y proporciona sus piezas favoritas que parecen funcionar como sugiere su título. Sin embargo, una de las cosas de las que me preocupo cuando veo cosas que apoyan las mejores y más recientes prácticas de desarrollo de software es una fuerte tendencia hacia el sesgo de confirmación - de buscar la confirmación de las teorías actuales y pasar por alto los contraindicadores.
Por lo tanto, ser curioso y como TDD es algo que estoy vigilando para ver si es algo que me gustaría adoptar algún día, ingresé en el informe ...
... sin lugar a dudas, las pruebas primero llevan 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, al igual que no me sorprende que la cantidad de líneas de código no corresponda a la productividad.
El autor tiene muchos puntos positivos en cuanto a que la TDD no es tan efectiva (a pesar de haber sido exagerada)
observe cuánto tiempo usted y el cliente pasaron a probar el software manualmente; compare eso con una estimación de cuánto tiempo habrían tomado las pruebas automatizadas de estilo TDD. Embolsar la diferencia
En mi experiencia, las pruebas automatizadas de TDD son gold porque proporcionan seguros y eliminan enormes cantidades de pruebas manuales
como señaló Andrés 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 idea de último momento o agradable de tener
Al ser forzado a pensar en probar primero, 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 realmente tiene que hacer el código en tu mente mientras escribes el código, en lugar de hacer una especie de cálculo. fuera-como-tu-código.
desea justificarlo: sugiérale que lo haga para el próximo proyecto y luego aprenda de él. Si resulta que funciona bien para usted, espero que continúe usándolo y si le tomó más tiempo realizar el proyecto y / o dedicar todo su tiempo a escribir pruebas en lugar de codificar, entonces seguramente lo dejará 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, 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 trabajé en ese momento, todos estábamos reacios a usar, incluidos los gerentes. Sin embargo, pronto se convirtió en lo correcto. Los beneficios que pronto notamos fueron
Los gerentes no sabrían ya que todos están interesados en una cosa: "¿Ya terminaste?". Pero luego se quejan cuando el software sigue rompiendo sin darse cuenta. Con una buena cobertura y pruebas sensatas. No es la cantidad sino la calidad que se puede ver cuando alguien rompe una funcionalidad. Desafortunadamente, también es difícil si está solo. Tenía el mismo problema, ya que es posible que necesite cambiar el código, por ejemplo, las clases base, etc. para que pueda hacer que algunas partes del software sean verificables.
Te doy un ejemplo. Quería burlarme del repositorio pero no había ninguna 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 una gran trato pero al final tengo más de 200 pruebas que solo prueban un área del sistema y quedaron impresionados.
Normalmente hago lo siguiente:
En cuanto a los estudios de caso, me temo que no estoy seguro de haber visto ninguno. Necesitas construir tu proyecto y convertirte en tus estudios de caso. También podrían estar impresionados.
Espero que ayude
Lea otras preguntas en las etiquetas tdd