Hemos estado recabado en todo internet para así regalarte la respuesta a tu duda, si tienes alguna duda puedes dejar la inquietud y te respondemos con mucho gusto.
Solución:
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 On Test Cobertura
Una mañana temprano, un programador le preguntó al gran maestro:
“Estoy listo para escribir algunas pruebas unitarias. ¿A qué cobertura de código debería apuntar? “
El gran maestro respondió:
“No se preocupe por la cobertura, solo 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, perplejo, respondió:
“¿Cómo puedo decírtelo? Depende de cuántas personas necesites alimentar, qué tan hambrientas estén, qué otros alimentos sirvas, 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 e hizo 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 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 acaba de empezar con las pruebas. Ahora mismo tiene mucho código y ninguna prueba. 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 que se acostumbre a escribir y hacer 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 hay una respuesta única y simple, y ella 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 y única, ¿por qué respondió al tercer programador ‘Ochenta por ciento y nada menos’?”
El gran maestro rió tan fuerte y fuerte que su barriga, evidencia de que bebía más que té verde, se agitó hacia arriba y hacia 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 un silencio contemplativo.
La cobertura de código es una métrica engañosa si su objetivo es una cobertura del 100% (en lugar de probar al 100% todas las funciones).
- Podrías obtener un 100% pulsando todas las líneas una vez. Sin embargo, aún podría perderse probar una secuencia particular (ruta lógica) en la que se golpean 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 ExceptionTypeX’ o un protector de programación defensivo similar que haya puesto es un ‘bueno tener’, no un ‘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 cobertura mágica del 100%. Si TDD su código, debería obtener una cobertura de más del 90% como bonificación. Use la cobertura de código para resaltar fragmentos de código que se ha perdido (aunque no debería suceder si utiliza TDD … ya que escribe código solo para realizar una prueba. Ningún código puede existir sin la prueba de su socio).
La respuesta aceptada tiene un buen punto: no hay un solo número que tenga sentido como estándar para cada proyecto. Hay proyectos que simplemente no necesitan tal estándar. Donde la respuesta aceptada se queda corta, en mi opinión, es en describir cómo se podría tomar esa decisión para un proyecto dado.
Intentaré hacerlo. No soy un experto en ingeniería de pruebas y estaría feliz de ver una respuesta más informada.
Cuándo establecer los requisitos de cobertura del código
Primero, ¿por qué querría imponer tal estándar en primer lugar? En general, cuando desee introducir confianza empírica en su proceso. ¿Qué quiero decir con “confianza empírica”? Bueno, el verdadero objetivo exactitud. Para la mayoría del software, no podemos saber esto en todas las entradas, por lo que nos conformamos con decir que el código es bien probado. Esto es más cognoscible, pero sigue siendo un estándar subjetivo: siempre estará abierto al debate si lo ha cumplido o no. Esos debates son útiles y deberían ocurrir, pero también exponen incertidumbre.
Cobertura de código es una medida objetiva: una vez que vea su informe de cobertura, no hay ambigüedad acerca de si se han cumplido los estándares que son útiles. ¿Prueba la corrección? En absoluto, pero tiene una clara relación con qué tan bien probado está el código, que a su vez es nuestra mejor manera de aumentar la confianza en su exactitud. La cobertura del código es una aproximación mensurable de cualidades inconmensurables que nos preocupan.
Algunos casos específicos en los que tener un estándar empírico podría agregar valor:
- Satisfacer a los grupos de interés. Para muchos proyectos, hay varios actores interesados en la calidad del software que pueden no estar involucrados en el desarrollo diario del software (gerentes, líderes técnicos, etc.) diciendo “vamos a escribir todos los pruebas que realmente necesitamos “no es convincente: necesitan confiar completamente o verificar con una supervisión cercana continua (asumiendo que incluso tienen el conocimiento técnico para hacerlo). Proporcionar estándares medibles y explicar cómo se aproximan razonablemente a los objetivos reales es mejor.
- Normalizar el comportamiento del equipo. Dejando a un lado las partes interesadas, si está trabajando en un equipo en el que varias personas escriben código y pruebas, hay espacio para la ambigüedad en 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 clientes potenciales pueden no tener una supervisión directa sobre los desarrolladores junior, por ejemplo. Las redes de confianza también son importantes, pero sin medidas objetivas, es fácil que el comportamiento del grupo se vuelva inconsistente, incluso si todos actúan de buena fe.
- Para mantenerse honesto. Incluso si eres el único desarrollador y la única parte interesada de tu proyecto, es posible que tengas 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 usar la cobertura del código como una aproximación razonable y dejar que las máquinas lo 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. Sobre 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ía usarlas para establecer estándares:
- Cobertura de estados de cuenta: ¿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 usa cobertura de código para asegurarse ese las cosas se prueban (y no como un indicador de la calidad de la prueba más allá de eso), entonces la cobertura de la declaración es probablemente suficiente.
- Cobertura de sucursales: Cuando hay una lógica de bifurcación (p. Ej.
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 en un conjunto completo de insumos. Si está utilizando la cobertura de código como su mejor aproximación empírica para la confianza en la exactitud, 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 diferentes resultados numéricos para declaraciones de varias líneas, por ejemplo; la cobertura condicional y la cobertura de ruta es similar a la cobertura de sucursal, pero refleja una vista más detallada de las posibles permutaciones de ejecución del programa que puede encontrar.)
Que porcentaje requerir
Finalmente, volviendo 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 estamos hablando de una aproximación para empezar, por lo que cualquier número que elijamos será inherentemente aproximado.
Algunos números que uno puede elegir:
- 100%. Puede elegir esto porque quiere asegurarse de que todo esté probado. Esto no le da ninguna idea de la calidad de la prueba, pero le dice que alguna prueba de cierta calidad ha afectado a cada declaración (o rama, etc.) Nuevamente, esto vuelve al grado de confianza: si su cobertura está por debajo del 100% , usted saber algún subconjunto de su código no está probado.
- Algunos podrían argumentar que esto es una tontería y que solo debe probar las partes de su código que son realmente importantes. Yo diría que también debe mantener solo las partes de su código que son realmente importantes. La cobertura del código también se puede mejorar eliminando 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 la esquina 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. I pensar 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ía 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 significar por la mayoría). Esto es apropiado para casos intermedios en los que “bien probado” no es una prioridad alta (no desea desperdiciar esfuerzo en pruebas de bajo valor), pero es una prioridad lo suficientemente importante como para quisiera tener algún estándar en su lugar.
No he visto números por debajo del 80% en la práctica, y me cuesta imaginar un caso en el que uno los establezca. El papel de estos estándares es aumentar la confianza en la corrección, y los números por debajo del 80% no inspiran confianza. (Sí, esto es subjetivo, pero nuevamente, la idea es tomar la decisión subjetiva una vez cuando establezca el estándar, y luego usar una medición objetiva en el futuro).
Otras notas
Lo anterior asume 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 capacidad de mantenimiento, probablemente le interese el acoplamiento suelto, que se puede demostrar mediante la capacidad de prueba, que a su vez se puede medir (en ciertas formas) mediante la cobertura del código. Por lo tanto, su estándar de cobertura de código también proporciona una base empírica para aproximar la calidad de la “capacidad de mantenimiento”.
Sección de Reseñas y Valoraciones
Tienes la opción de añadir valor a nuestra información dando tu veteranía en las notas.