¿Cuál es un porcentaje de cobertura de código razonable para pruebas unitarias (y por qué)? [cerrado]
Si tuviera que exigir un porcentaje mínimo de cobertura de código para las pruebas unitarias, tal vez incluso como requisito para comprometerse con un repositorio, ¿cuál sería?
Explique cómo llegó a su respuesta (ya que si todo lo que hizo fue elegir un número, entonces podría haberlo hecho yo solo;)
Esta prosa de Alberto Savoia responde precisamente a esa pregunta (¡de una manera muy entretenida!):
http://www.artima.com/forums/flat.jsp?forum=106&thread=204677
Testivus sobre la cobertura de la prueba
Una mañana temprano, un programador preguntó al gran maestro:
“Estoy listo para escribir algunas pruebas unitarias. ¿A qué cobertura de código debo aspirar?
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 con agua hirviendo y dijo:
“¿Cuántos granos de arroz debo poner en esa olla?”
El programador, desconcertado, respondió:
“¿Cómo podría decírtelo? Depende de cuántas personas necesites alimentar, del hambre que tengan, de qué otros alimentos les sirvas, de cuánto arroz tengas disponible, etc.
“Exactamente”, dijo el gran maestro.
El segundo programador sonrió, hizo una reverencia y se fue.
...
Hacia el final del día, vino un tercer programador y formuló la misma pregunta sobre la cobertura del código.
“¡Ochenta por ciento y nada menos!” Respondió el maestro con voz severa, golpeando la mesa con el puño.
El tercer programador sonrió, hizo una reverencia y se fue.
...
Tras 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 poco de té fresco conmigo y hablemos de ello".
Después de llenar sus tazas con té verde humeante y caliente, el gran maestro comenzó a responder:
“El primer programador es nuevo y recién está comenzando a realizar pruebas. En este momento tiene mucho código y ninguna prueba. Le queda un largo camino por recorrer; centrarse en la cobertura del código en este momento sería deprimente y bastante inútil. Es mejor que se acostumbre a escribir y realizar 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, la 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 existe una respuesta única y sencilla, y ella es lo suficientemente inteligente como para manejar la verdad y trabajar con ella”.
"Ya veo", dijo el joven aprendiz, "pero si no hay una respuesta única y sencilla, ¿por qué le 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ó algo más que té verde, se balanceó arriba y abajo.
"El tercer programador sólo quiere respuestas simples, incluso cuando no hay respuestas simples... y luego no las sigue de todos modos".
El joven aprendiz y el canoso gran maestro terminaron de beber su té en silencio contemplativo.
La cobertura del código es una métrica engañosa si su objetivo es una cobertura del 100 % (en lugar de probar el 100 % de todas las funciones).
- Podrías obtener un 100% si tocas todas las líneas una vez. Sin embargo, aún podría perderse la prueba de una secuencia particular (ruta lógica) en la que se alcanzan esas líneas.
- No pudo obtener un 100%, pero aún así ha probado todas las rutas de código utilizadas al 80%/frecuencia. Tener pruebas que prueben cada 'lanzamiento de ExceptionTypeX' o protección de programación defensiva similar que haya implementado es algo 'bueno de tener', no algo 'imprescindible'.
Así que confíe en usted mismo o en sus desarrolladores para ser minuciosos y cubrir todos los caminos a través de su código. Sea pragmático y no persiga la mágica cobertura del 100%. Si envía TDD a su código, debería obtener una cobertura superior al 90 % como bonificación. Utilice la cobertura de código para resaltar fragmentos de código que se ha perdido (aunque no debería suceder si realiza TDD... ya que escribe código solo para realizar una prueba. Ningún código puede existir sin su prueba asociada).
Jon Limjap tiene un buen punto: no hay un único número que tenga sentido como estándar para cada proyecto. Hay proyectos que simplemente no necesitan ese estándar. En mi opinión, donde la respuesta aceptada se queda corta es en describir cómo se podría tomar esa decisión para un proyecto determinado.
Intentaré hacerlo. No soy un experto en ingeniería de pruebas y me encantaría ver una respuesta más informada.
Cuándo establecer los requisitos de cobertura del código
En primer lugar, ¿por qué querrías imponer semejante estándar? En general, cuando desee introducir confianza empírica en su proceso. ¿Qué quiero decir con "confianza empírica"? Bueno, la verdadera corrección del objetivo . Para la mayoría del software, no es posible saber esto en todas las entradas, por lo que nos conformamos con decir que el código está bien probado . Esto es más fácil de conocer, pero sigue siendo un estándar subjetivo: siempre estará abierto al debate si lo has cumplido o no. Esos debates son útiles y deberían realizarse, pero también exponen incertidumbre.
La cobertura del código es una medición objetiva: una vez que vea su informe de cobertura, no hay ambigüedad sobre si los estándares que se han cumplido son útiles. ¿Prueba esto que es correcto? En absoluto, pero tiene una relación clara con qué tan bien probado está el código, lo que a su vez es nuestra mejor manera de aumentar la confianza en su corrección. La cobertura del código es una aproximación mensurable de cualidades inconmensurables que nos importan.
Algunos casos específicos donde contar con un estándar empírico podría agregar valor:
- Satisfacer a las partes interesadas. Para muchos proyectos, hay varios actores que tienen interés en la calidad del software y que pueden no estar involucrados en el desarrollo diario del software (gerentes, líderes técnicos, etc.) que dicen "vamos a escribir todos los "Las pruebas que realmente necesitamos" no es convincente: deben confiar plenamente o verificar con una supervisión estrecha y continua (asumiendo que incluso tengan el conocimiento técnico para hacerlo). Es mejor proporcionar estándares mensurables y explicar cómo se aproximan razonablemente a los objetivos reales.
- Normalizar el comportamiento del equipo. Dejando a un lado a las partes interesadas, si trabaja en un equipo en el que varias personas escriben código y pruebas, hay lugar para la ambigüedad en cuanto a lo que se considera "bien probado". ¿Todos sus colegas tienen la misma idea de qué nivel de prueba es suficientemente bueno? Probablemente no. ¿Cómo concilias esto? Encuentre una métrica en la que todos puedan estar de acuerdo y acéptela como una aproximación razonable. Esto es especialmente (pero no exclusivamente) útil en equipos grandes, donde los líderes pueden no tener supervisión directa sobre los desarrolladores junior, por ejemplo. Las redes de confianza también son importantes, pero sin mediciones objetivas, es fácil que el comportamiento del grupo se vuelva inconsistente, incluso si todos actúan de buena fe.
- Para ser honesto. Incluso si usted es el único desarrollador y el único interesado en su proyecto, es posible que tenga ciertas cualidades en mente para el software. En lugar de realizar evaluaciones subjetivas continuas sobre qué tan bien probado está el software (lo que requiere trabajo), puede utilizar la cobertura del código como una aproximación razonable y dejar que las máquinas la midan por usted.
Qué métricas usar
La cobertura del código no es una métrica única; Hay varias formas diferentes de medir la cobertura. Cuál podría establecer un estándar depende de para qué esté utilizando ese estándar para satisfacer.
Usaré dos métricas comunes como ejemplos de cuándo podrías usarlas para establecer estándares:
- Cobertura de declaraciones : ¿Qué porcentaje de declaraciones se han ejecutado durante las pruebas? Útil para tener una idea de la cobertura física de su código: ¿Cuánto del código que he escrito he probado realmente?
- Este tipo de cobertura respalda un argumento de corrección más débil, pero también es más fácil de lograr. Si solo está utilizando la cobertura del código para garantizar que las cosas se prueben (y no como un indicador de la calidad de la prueba más allá de eso), entonces la cobertura de la declaración probablemente sea suficiente.
- Cobertura de sucursales : cuando hay lógica de ramificación (por ejemplo, una
if), ¿se han evaluado ambas ramas? Esto da una mejor idea de la cobertura lógica de su código: ¿Cuántas de las posibles rutas que puede tomar mi código he probado?- Este tipo de cobertura es un indicador mucho mejor de que un programa ha sido probado a través de un conjunto integral de insumos. Si utiliza la cobertura de código como su mejor aproximación empírica para confiar en la corrección, debe establecer estándares basados en la cobertura de sucursales o similar.
Hay muchas otras métricas (la cobertura de línea es similar a la cobertura de declaración, pero produce resultados numéricos diferentes para declaraciones de varias líneas, por ejemplo; la cobertura condicional y la cobertura de ruta son similares a la cobertura de rama, pero reflejan una vista más detallada de las posibles permutaciones de ejecución del programa que podría encontrar.)
Que porcentaje exigir
Finalmente, volvamos a la pregunta original: si establece estándares de cobertura de código, ¿cuál debería ser ese número?
Con suerte, en este punto está claro que, para empezar, estamos hablando de una aproximación, por lo que cualquier número que elijamos será inherentemente aproximado.
Algunos números que uno podría elegir:
- 100% . Puede elegir esto porque quiere asegurarse de que todo esté probado. Esto no le brinda ninguna idea sobre la calidad de la prueba, pero le indica que alguna prueba de cierta calidad ha afectado a cada declaración (o rama, etc.). Nuevamente, esto se refiere al grado de confianza: si su cobertura es inferior al 100 % , sabes que algún subconjunto de tu código no se ha probado.
- Algunos podrían argumentar que esto es una tontería y que sólo deberías probar las partes de tu código que sean realmente importantes. Yo diría que también deberías mantener sólo las partes de tu código que sean realmente importantes. La cobertura del código se puede mejorar eliminando también el código no probado.
- 99% (o 95%, otras cifras en los noventa). Apropiado en los casos en los que desea transmitir un nivel de confianza similar al 100%, pero déjese un margen para no preocuparse por algún rincón ocasional difícil de probar. código.
- 80% . He visto este número en uso varias veces y no sé del todo dónde se origina. Creo que podría ser una extraña apropiación indebida de la regla 80-20; En general, la intención aquí es mostrar que la mayor parte de su código se prueba. (Sí, el 51% también sería "la mayoría", pero el 80% refleja más lo que la mayoría de la gente quiere decir con la mayoría). Esto es apropiado para casos intermedios donde "bien probado" no es una alta prioridad (no No quiero desperdiciar esfuerzos en pruebas de bajo valor), pero es una prioridad suficiente como para que aún le gustaría tener algún estándar implementado.
No he visto números por debajo del 80% en la práctica y me cuesta imaginar un caso en el que se pudieran establecer. La función de estos estándares es aumentar la confianza en la corrección, y las cifras por debajo del 80% no inspiran particularmente confianza. (Sí, esto es subjetivo, pero nuevamente, la idea es hacer la elección subjetiva una vez cuando se establece el estándar y luego usar una medición objetiva en el futuro).
Otras notas
Lo anterior supone que la corrección es el objetivo. La cobertura del código es solo información; puede ser relevante para otros objetivos. Por ejemplo, si le preocupa la mantenibilidad, probablemente le interese el acoplamiento flexible, que puede demostrarse mediante la capacidad de prueba, que a su vez puede medirse (en ciertas formas) mediante la cobertura del código. Por lo tanto, el estándar de cobertura de su código también proporciona una base empírica para aproximar la calidad de la "mantenibilidad".
La cobertura del código es excelente, pero la cobertura de la funcionalidad es aún mejor. No creo en cubrir cada línea que escribo. Pero sí creo en escribir una cobertura de prueba del 100% de todas las funciones que quiero proporcionar (incluso para las características adicionales interesantes que vine con mí mismo y que no se discutieron durante las reuniones).
No me importa si tengo un código que no está cubierto en las pruebas, pero sí me importa si refactorizo mi código y termino teniendo un comportamiento diferente. Por lo tanto, mi único objetivo es una cobertura de funcionalidad del 100%.
