El costo de las pruebas unitarias
La prueba de unidad es un tema recurrente para mí estas últimas semanas; entre hablando stackoverflow y otros foros y en los ensayos que yo le escribo dos proyectos en curso, Le pregunté a algunas preguntas sobre el costo real de las pruebas unitarias.
Esto es especialmente un artículo de Thomas Brandt (Alemán: “TDD in der (mi) Prácticas - deseo y la realidad”) que me hizo pensar seriamente. Brandt describe en su artículo muy bien hecho, este abismo entre la teoría y la práctica de Test Driven Development. Punto blanco, Más bien, se adhiere a los principios de TDD;
En primer lugar hay que decir que Test Driven Development, especialmente el principio de "primera prueba", es un lugar “sexy” desarrollar. Ciertamente, puede mejorar la arquitectura de software y nos impide hacer ciertas (pequeños) errores.
— traducción relativamente libre de cerca de T. Brandt
Por lo tanto, considera TDD como una poderosa herramienta – al menos desde el puramente académico. Pero el resultado inmediato es una duda;
La cuestión es simplemente: ¿a qué precio?
Como se ha mencionado, excepto T. Brandt y yo, muchas otras personas parecen pedir, y la pregunta más frecuente es el siguiente: Es que el uso de pruebas unitarias de software que hace realmente mejor, y es que los esfuerzos para invertir son realistas?
Condensada, la cuestión se reduce a una simple:
Me costó la cantidad de las pruebas unitarias?
A menudo, la cuestión consiste en, que el que plantea que las pruebas unitarias son demasiado caros para aplicar de forma coherente. Recuerdo una discusión que tenía sobre el valor de una cobertura total de la prueba más allá del ideal teórico. los esfuerzos se informa de que proporcionan dije “no” en el momento.
Al día de hoy creo que todas estas preguntas se les pide simplemente el mal, porque no se conoce el costo de las pruebas unitarias es importante, más:
¿Cómo puedo pagar la omisión de pruebas unitarias?
Y aquí está mi respuesta, se ilustra con un ejemplo concreto;
Uno de mis proyectos actuales incluyen un gran número de componentes distribuidos. He descubierto un error en el proyecto de, que me obligó a refactorizar ambas clases. Todos me tomó alrededor de 1 horas. Lanzamiento de pruebas unitarias? Acerca de 30 segundo. 30 segundo, descubrí que algunos comportamientos no fueron como estaba previsto. Me tomó unos 20 minutos para las correcciones. Escribir las pruebas me costó alrededor de 45 minutos.
El balance es de dos horas.
Sin pruebas unitarias, Probablemente no se daría cuenta de algunos de los errores de inmediato. Habría tenido 1 tiempo refactorización, más de un más o menos determinable, sin duda, repartidas en varios días, para corregir los problemas que pasan desapercibidos cuando se cambia. La probabilidad de que esta vez va más allá de una hora es relativamente alta (depuración “mano”, recrear las condiciones en las aplicaciones de subprocesos múltiples, etc…).
Por mi parte, Me parece que para calcular un tiempo definido (pruebas con que cubra una parte realista del software – no 100%) más interesante es que la navegación en la oscuridad, tal como se practica.
Experimento!



