¿Cuál es el estado actual de la técnica con respecto al porcentaje de cobertura de código óptimo para las pruebas unitarias?

Esta es una pregunta para Testivus. En realidad, una pregunta que ya respondió hace mucho tiempo. Y es poco probable que la respuesta cambie. Siempre.

Testivus en cobertura de prueba

Una mañana temprano, un programador le preguntó al gran maestro:

“Estoy listo para escribir algunas pruebas unitarias. ¿Qué código de cobertura debo buscar?

El gran maestro respondió:

“No se preocupe por la cobertura, simplemente escriba algunas buenas pruebas”.

El programador sonrió, hizo una reverencia y se fue.

…

Más tarde ese día, un segundo programador hizo la misma pregunta.

El gran maestro señaló una olla de agua hirviendo y dijo:

“¿Cuántos granos de arroz deberían poner en esa olla?”

El programador, confundido, respondió:

“¿Cómo puedo decírtelo? Depende de cuántas personas necesita alimentar, qué tan hambrientos están, qué otra comida está sirviendo, cuánto arroz tiene disponible, etc. ”.

“Exactamente”, dijo el gran maestro.

El segundo programador sonrió, hizo una reverencia y se fue.

…

Hacia el final del día, llegó un tercer programador y le hizo la misma pregunta sobre la cobertura del código.

“¡Ochenta por ciento y nada menos!”, Respondió el maestro con voz severa, golpeando su puño sobre la mesa.

El tercer programador sonrió, hizo una reverencia y se fue.

…

Después de esta última respuesta, un joven aprendiz se acercó al gran maestro:

“Gran maestro, hoy te escuché responder la misma pregunta sobre la cobertura del código con tres respuestas diferentes. ¿Por qué?”

El gran maestro se levantó de su silla:

“Ven a tomar un té fresco conmigo y hablemos de ello”.

Después de llenar sus tazas con té verde caliente humeante, el gran maestro comenzó a responder:

“El primer programador es nuevo y recién está comenzando con las pruebas. En este momento tiene mucho código y no tiene pruebas. Tiene un largo camino por recorrer; centrarse en la cobertura del código en este momento sería deprimente y bastante inútil. Es mejor acostumbrarse a escribir y ejecutar algunas pruebas. Puede preocuparse por la cobertura más tarde “.

“El segundo programador, por otro lado, tiene bastante experiencia tanto en programación como en pruebas. Cuando le respondí preguntándole cuántos granos de arroz debería poner en una olla, le ayudé a darse cuenta de que la cantidad de pruebas necesarias depende de varios factores, y ella conoce esos factores mejor que yo, después de todo es su código. . No hay una respuesta única y simple, y es lo suficientemente inteligente como para manejar la verdad y trabajar con eso ”.

“Ya veo”, dijo el joven aprendiz, “pero si no hay una respuesta simple, entonces ¿por qué respondiste al tercer programador ‘Ochenta por ciento y nada menos’?”

El gran maestro se rió tan fuerte y fuerte que su barriga, evidencia de que bebió más que té verde, se dejó caer de arriba abajo.

“El tercer programador solo quiere respuestas simples, incluso cuando no hay respuestas simples … y luego no las sigue de todos modos”.

El joven aprendiz y el gran maestro canoso terminaron de beber su té en silencio contemplativo.

Fuente original de lo anterior aquí: ¿Cuánta cobertura de prueba unitaria necesita?

Muchas personas estarán de acuerdo en que las pruebas de mutación pueden considerarse “estado del arte” en el momento en que se trata de pruebas. Al menos es un tema bastante candente y se investiga mucho en los últimos años. La prueba de mutación realiza pequeños cambios en el programa que se está probando, luego ejecuta el conjunto de pruebas para descubrir qué tan bueno es ese conjunto. En otras palabras, si puede detectar los cambios que se introdujeron.

Existe un debate sobre si tener una buena cobertura LOC / sucursal es lo suficientemente bueno o si deberíamos esforzarnos por una cobertura de mutación del 100%. Hice un pequeño experimento y publiqué los resultados en mi blog: Prueba de mutación vs. Cobertura.

Como resultado, ni el 100% de cobertura de sucursal / LOC, ni el 100% de cobertura de mutación pudieron detectar un error conocido en el programa. Lo que es aún más interesante es que hubo un segundo error que ninguna de las herramientas pudo detectar y requirió una tercera herramienta para detectarlo.

Fácil: 100%

No garantiza la calidad de ninguna manera. Da muchos otros buenos beneficios:

1. Se asegura de que no tenga código no utilizado.
2. Se asegura de que no haya código que no sepa cómo probar.
3. Se asegura de que no haya un solo componente lento \ inestable para el que no sepa cómo hacer una prueba doble para
4. etc.

Ahora, muchas personas le dirán que es difícil obtener el 100%. De hecho, es bastante difícil aprender todas las mejores prácticas. Una vez que sabes qué hacer, no es tan difícil.

Por cierto: no es “estado del arte”. Lo hago todos los días de 9 a 5 en una compañía de software normal.