¿Cuál es un porcentaje de cobertura de código razonable para pruebas unitarias (y por qué)?[cerrado]

https://stackoverflow.com/questions/90002

01-07-2019
|

Pregunta

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;)

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 sobre la cobertura de la prueba

Temprano una mañana, un programador le preguntó al gran maestro:

“Estoy listo para escribir algunas pruebas unitarias.¿A qué cobertura de código debo apuntar?

El gran maestro respondió:

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

El programador sonrió, se inclinó 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 debo poner en esa olla?”

El programador, luciendo perplejo, respondió:

“¿Cómo podría decírtelo?Depende de cuántas personas necesite alimentar, cuán hambrientas son, qué otros alimentos están sirviendo, cuánto arroz tiene disponible, etc.

“Exactamente”, dijo el gran maestro.

El segundo programador sonrió, se inclinó y se fue.

...

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

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

El tercer programador sonrió, se inclinó y se fue.

...

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

“Gran maestro, hoy escuché que responde la misma pregunta sobre la cobertura de código con tres respuestas diferentes.¿Por qué?"

El gran maestro se puso de pie 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 caliente fumar, 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 sin pruebas.Le queda un largo camino por recorrer;Centrarse en la cobertura de 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, es bastante experiencia tanto en programación como en pruebas.Cuando respondí preguntándole cuántos granos de arroz debo 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: es su código después de todo. .No hay respuesta simple, 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, ¿por qué respondiste al tercer programador 'ochenta por ciento y nada menos'?"

El gran maestro se rió tan fuerte y fuerte que su vientre, evidencia que bebió más que solo té verde, fracasó arriba y 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 Grizzled terminaron de beber su té en silencio contemplativo.

Otros consejos

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.)

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 ofrecer (incluso para las características adicionales interesantes que traje yo 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 importaría refactorizar mi código y terminar teniendo un comportamiento diferente.Por lo tanto, mi único objetivo es una cobertura de funcionalidad del 100%.

La respuesta aceptada tiene razón: no hay un solo 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, el verdadero objetivo. exactitud.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 es bien probado.Esto es más comprensible, 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.

Cobertura de código es una medida objetiva:Una vez que vea su informe de cobertura, no habrá ambigüedad sobre si los estándares cumplidos 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 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 de lado las partes interesadas, si está trabajando en un equipo donde varias personas escriben código y pruebas, hay espacio para la ambigüedad de lo que califica como "bien probado". ¿Todos sus colegas tienen la misma idea de qué nivel de prueba es lo 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 declaración:¿Qué porcentaje de declaraciones se han ejecutado durante las pruebas?Útil para tener una idea del cobertura fisica de tu 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ás usando cobertura de código para asegurar eso 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 probablemente sea suficiente.
Cobertura de sucursales:Cuando hay lógica de bifurcación (p. ej.un if), ¿se han evaluado ambas ramas?Esto da una mejor idea de la cobertura lógica de tu 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 la ejecución del programa que puede 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 sí le indica que alguna prueba de cierta calidad ha tocado cada declaración (o rama, etc.). Nuevamente, esto vuelve al grado de confianza:Si su cobertura es inferior al 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 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éjate un margen para no preocuparte por algún rincón ocasional del código difícil de probar.
80%.He visto este número en uso varias veces y no sé del todo dónde se origina.I pensar podría tratarse de una extraña apropiación indebida de la regla 80-20;En general, la intención aquí es mostrar que 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 donde "bien probado" no es una alta prioridad (no desea desperdiciar esfuerzo en pruebas de bajo valor), pero es una prioridad suficiente que aún así 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 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".

Mi cobertura de código favorita es 100% con un asterisco.El asterisco viene porque prefiero usar herramientas que me permitan marcar ciertas líneas como líneas que "no cuentan".Si he cubierto el 100% de las líneas que "cuentan", ya he terminado.

El proceso subyacente es:

Escribo mis pruebas para ejercitar todas las funciones y casos extremos que se me ocurren (normalmente trabajando a partir de la documentación).
Ejecuto las herramientas de cobertura de código.
Examino las líneas o caminos no cubiertos y los que considero no importantes o inalcanzables (debido a la programación defensiva) los marco como sin contar.
Escribo nuevas pruebas para cubrir las líneas que faltan y mejorar la documentación si no se mencionan esos casos extremos.

De esta manera, si mis colaboradores y yo agregamos código nuevo o cambiamos las pruebas en el futuro, hay una línea brillante que nos indica si nos perdimos algo importante: la cobertura cayó por debajo del 100%.Sin embargo, también proporciona la flexibilidad para abordar diferentes prioridades de prueba.

Tendría otra anécdota sobre la cobertura de la prueba que me gustaría compartir.

Tenemos un proyecto enorme en el que, a través de twitter, noté que, con 700 pruebas unitarias, solo tenemos una cobertura de código del 20%.

Scott Hanselman respondió con palabras de la sabiduría:

¿Es el 20% CORRECTO?¿Es el 20% el que representa el código que más alcanzan sus usuarios?Puede agregar 50 pruebas más y solo agregar 2%.

De nuevo, vuelve a mi Testivus sobre la cobertura del código Respuesta.¿Cuánto arroz debes poner en la olla?Eso depende.

Si este fuera un mundo perfecto, el 100% del código estaría cubierto por pruebas unitarias.Sin embargo, dado que este NO es un mundo perfecto, es una cuestión de para qué tienes tiempo.Como resultado, recomiendo centrarse menos en un porcentaje específico y más en las áreas críticas.Si su código está bien escrito (o al menos una copia razonable del mismo), debería haber varios puntos clave donde las API estén expuestas a otro código.

Concentre sus esfuerzos de prueba en estas API.Asegúrese de que las API estén 1) bien documentadas y 2) tengan casos de prueba escritos que coincidan con la documentación.Si los resultados esperados no coinciden con los documentos, entonces tiene un error en su código, documentación o casos de prueba.Todo lo cual es bueno examinar.

¡Buena suerte!

Para un sistema bien diseñado, donde las pruebas unitarias han impulsado el desarrollo desde el principio, diría que el 85% es un número bastante bajo.Las clases pequeñas diseñadas para ser examinables no deberían ser difíciles de cubrir mejor que eso.

Es fácil descartar esta pregunta con algo como:

Las líneas cubiertas no equivalen a la lógica probada y no se debe interpretar demasiado el porcentaje.

Es cierto, pero hay algunos puntos importantes que destacar sobre la cobertura del código.En mi experiencia, esta métrica es bastante útil cuando se usa correctamente.Dicho esto, no he visto todos los sistemas y estoy seguro de que hay toneladas de ellos en los que es difícil ver que el análisis de cobertura de código agregue algún valor real.El código puede verse muy diferente y el alcance del marco de prueba disponible puede variar.

Además, mi razonamiento se refiere principalmente a ciclos de retroalimentación de prueba bastante cortos.Para el producto que estoy desarrollando, el circuito de retroalimentación más corto es bastante flexible y cubre todo, desde pruebas de clase hasta señalización entre procesos.Probar un subproducto entregable normalmente toma 5 minutos y, para un ciclo de retroalimentación tan corto, es posible usar los resultados de la prueba (y específicamente la métrica de cobertura de código que estamos viendo aquí) para rechazar o aceptar confirmaciones en el repositorio.

Al utilizar la métrica de cobertura de código, no debe limitarse a tener un porcentaje fijo (arbitrario) que deba cumplirse. En mi opinión, hacer esto no le brinda los beneficios reales del análisis de cobertura de código.En su lugar, defina las siguientes métricas:

Low Water Mark (LWM), el número más bajo de líneas descubiertas jamás visto en el sistema bajo prueba
High Water Mark (HWM), el porcentaje de cobertura de código más alto jamás visto para el sistema bajo prueba

Solo se puede agregar código nuevo si no superamos el LWM ni superamos el HWM.En otras palabras, la cobertura del código es no se permite disminuir, y se debe cubrir el código nuevo.Observe cómo digo debería y no debo (se explica a continuación).

¿Pero no significa esto que será imposible limpiar la basura vieja y probada que ya no sirve?Sí, y por eso hay que ser pragmático en estas cosas.Hay situaciones en las que es necesario romper las reglas, pero para la integración típica del día a día, mi experiencia es que estas métricas son bastante útiles.Dan las siguientes dos implicaciones.

Se promueve el código comprobable.Al agregar código nuevo, realmente debe hacer un esfuerzo para que el código sea comprobable, porque tendrá que intentar cubrirlo todo con sus casos de prueba.El código comprobable suele ser algo bueno.
La cobertura de pruebas para código heredado aumenta con el tiempo.Al agregar código nuevo y no poder cubrirlo con un caso de prueba, se puede intentar cubrir algún código heredado para eludir la regla LWM.Este engaño, a veces necesario, al menos tiene el efecto secundario positivo de que la cobertura del código heredado aumentará con el tiempo, lo que hace que la aplicación aparentemente estricta de estas reglas sea bastante pragmática en la práctica.

Y nuevamente, si el ciclo de retroalimentación es demasiado largo, podría resultar completamente poco práctico configurar algo como esto en el proceso de integración.

También me gustaría mencionar dos beneficios generales más de la métrica de cobertura de código.

El análisis de cobertura de código es parte del análisis de código dinámico (a diferencia del análisis estático, es decirHilas).Problemas encontrados durante el análisis de código dinámico (por herramientas como la familia purify, http://www-03.ibm.com/software/products/en/rational-purify-family) son cosas como lecturas de memoria no inicializadas (UMR), pérdidas de memoria, etc. Estos problemas sólo se pueden encontrar si el código está cubierto por un caso de prueba ejecutado..El código más difícil de cubrir en un caso de prueba suele ser el de los casos anormales en el sistema, pero si desea que el sistema falle sin problemas (es decir,seguimiento de error en lugar de bloqueo), es posible que también desee esforzarse en cubrir los casos anormales en el análisis de código dinámico.Con un poco de mala suerte, una UMR puede provocar una falla de segmento o algo peor.
La gente se enorgullece de conservar el 100% del código nuevo y discute los problemas de prueba con una pasión similar a la de otros problemas de implementación.¿Cómo se puede escribir esta función de una manera más comprobable?¿Cómo haría usted para tratar de cubrir este caso anormal, etc.?

Y una negativa, para completar.

En un proyecto grande con muchos desarrolladores involucrados, seguro que no todos serán genios de las pruebas. Algunas personas tienden a utilizar la métrica de cobertura del código como prueba de que el código está probado y esto está muy lejos de la verdad., como se menciona en muchas de las otras respuestas a esta pregunta.Es UNA métrica que puede brindarle algunos beneficios interesantes si se usa correctamente, pero si se usa mal, de hecho puede conducir a pruebas incorrectas.Aparte de los efectos secundarios muy valiosos mencionados anteriormente, una línea cubierta solo muestra que el sistema bajo prueba puede alcanzar esa línea para algunos datos de entrada y que puede ejecutarse sin colgarse ni fallar.

El 85% sería un buen punto de partida para los criterios de registro.

Probablemente elegiría una variedad de barras más altas para los criterios de envío, dependiendo de la importancia de los subsistemas/componentes que se están probando.

Muchas tiendas no valoran las pruebas, por lo que si está por encima de cero, al menos hay cierta apreciación del valor, por lo que podría decirse que un valor distinto de cero no es malo, ya que muchos todavía están en cero.

En el mundo .Net la gente suele citar el 80% como razonable.Pero lo dicen a nivel de solución.Prefiero medir a nivel de proyecto:El 30% podría estar bien para el proyecto de interfaz de usuario si tiene Selenium, etc. o pruebas manuales, el 20% para el proyecto de capa de datos podría estar bien, pero más del 95% podría ser bastante alcanzable para la capa de reglas de negocio, si no es totalmente necesario.Por tanto, la cobertura general puede ser, digamos, del 60%, pero la lógica empresarial crítica puede ser mucho mayor.

También he oído esto:aspira al 100% y alcanzarás el 80%;pero aspira al 80% y alcanzarás el 40%.

Línea de fondo:Aplica la regla 80:20 y deja que el recuento de errores de tu aplicación te guíe.

Yo uso cobertura, y sea cual sea el porcentaje, recomendaría mantener actualizados los valores en la tarea de verificación de cobertura.Como mínimo, siga aumentando la tasa total lineal y la tasa total de sucursales justo por debajo de su cobertura actual, pero nunca bajar esos valores.También vincule la propiedad de falla de compilación de Ant con esta tarea.Si la compilación falla debido a la falta de cobertura, usted conoce el código agregado de alguien pero no lo ha probado.Ejemplo:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

Cuando creo que mi código no se ha probado lo suficiente y no estoy seguro de qué probar a continuación, utilizo la cobertura para ayudarme a decidir qué probar a continuación.

Si aumento la cobertura en una prueba unitaria, sé que esta prueba unitaria vale algo.

Esto se aplica al código que no está cubierto, al 50% o al 97%.

La cobertura del código es solo otra métrica.En sí mismo, puede ser muy engañoso (ver www.thinkworks.com/insights/blog/are-test-coverage-metrics-overrate).Por lo tanto, su objetivo no debe ser lograr una cobertura de código del 100%, sino asegurarse de probar todos los escenarios relevantes de su aplicación.

Si ha estado realizando pruebas unitarias durante un tiempo decente, no veo ninguna razón para que no se acerque al 95%+.Sin embargo, como mínimo, siempre he trabajado con el 80%, incluso cuando soy nuevo en las pruebas.

Este número solo debe incluir código escrito en el proyecto (excluye marcos, complementos, etc.) y tal vez incluso excluir ciertas clases compuestas enteramente de código escrito a partir de llamadas a código externo.Este tipo de llamada debería ser objeto de burla o eliminación.

En términos generales, de los diversos artículos sobre mejores prácticas de excelencia en ingeniería que he leído, el 80% del código nuevo en pruebas unitarias es el punto que produce el mejor rendimiento.Superar ese CC% produce una menor cantidad de defectos por la cantidad de esfuerzo ejercido.Esta es una práctica recomendada que utilizan muchas corporaciones importantes.

Desafortunadamente, la mayoría de estos resultados son internos de las empresas, por lo que no hay literatura pública a la que pueda indicarle.

La cobertura del código es excelente, pero solo siempre que los beneficios que se obtengan superen el costo/esfuerzo de lograrlo.

Hemos estado trabajando con un estándar del 80 % durante algún tiempo, sin embargo, acabamos de tomar la decisión de abandonar esto y, en cambio, centrarnos más en nuestras pruebas.Centrándose en la compleja lógica empresarial, etc.

Esta decisión se tomó debido a la creciente cantidad de tiempo que dedicamos a buscar la cobertura del código y mantener las pruebas unitarias existentes.Sentimos que habíamos llegado al punto en el que se consideraba que el beneficio que obteníamos de la cobertura de nuestro código era menor que el esfuerzo que teníamos que realizar para lograrlo.

Prefiero hacer BDD, que utiliza una combinación de pruebas de aceptación automatizadas, posiblemente otras pruebas de integración y pruebas unitarias.La pregunta para mí es cuál debería ser la cobertura objetivo del conjunto de pruebas automatizadas en su conjunto.

Aparte de eso, la respuesta depende de su metodología, lenguaje y herramientas de prueba y cobertura.Al hacer TDD en Ruby o Python no es difícil mantener una cobertura del 100% y vale la pena hacerlo. Es mucho más fácil gestionar una cobertura del 100 % que una cobertura del 90 %. Es decir, es mucho más fácil cubrir las brechas de cobertura a medida que aparecen (y cuando se hace bien TDD, las brechas de cobertura son raras y generalmente valen la pena) que administrar una lista de brechas de cobertura a las que no ha llegado y pierde cobertura. regresiones debido a su constante fondo de código descubierto.

La respuesta también depende de la historia de su proyecto.Solo he encontrado que lo anterior es práctico en proyectos gestionados de esa manera desde el principio.He mejorado enormemente la cobertura de grandes proyectos heredados y valió la pena hacerlo, pero nunca me resultó práctico volver atrás y llenar todos los vacíos de cobertura, porque el código antiguo no probado no se comprende lo suficiente como para hacerlo correctamente y rápidamente.

Verificar Mierda4j.Es un enfoque ligeramente más sofisticado que la cobertura de código simple.Combina medidas de cobertura de código con medidas de complejidad y luego le muestra qué código complejo no se prueba actualmente.

Mi respuesta a este enigma es tener una cobertura de línea del 100% del código que puedes probar y una cobertura de línea del 0% del código que no puedes probar.

Mi práctica actual en Python es dividir mis módulos .py en dos carpetas:app1/ y app2/ y cuando ejecute pruebas unitarias calcule la cobertura de esas dos carpetas y verifique visualmente (I debe automatizar esto algún día) que la aplicación1 tiene una cobertura del 100% y la aplicación2 tiene una cobertura del 0%.

Cuando encuentro que estos números difieren del estándar, investigo y modifico el diseño del código para que la cobertura se ajuste al estándar.

Esto significa que puedo recomendar lograr una cobertura de línea del 100% del código de la biblioteca.

También reviso ocasionalmente app2/ para ver si es posible probar algún código allí y, si puedo, lo muevo a app1/

Ahora bien, no estoy demasiado preocupado por la cobertura agregada porque puede variar enormemente según el tamaño del proyecto, pero en general he visto entre el 70% y más del 90%.

Con Python, debería poder diseñar una prueba de humo que pueda ejecutar automáticamente mi aplicación mientras mido la cobertura y, con suerte, obtener un total del 100% al combinar la prueba de humo con cifras de prueba unitaria.

Ver la cobertura desde otra perspectiva:El código bien escrito con un flujo de control claro es el más fácil de cubrir, el más fácil de leer y, por lo general, el código con menos errores.Al escribir código teniendo en cuenta la claridad y la cobertura, y al escribir las pruebas unitarias en paralelo con el código, se obtienen los mejores resultados en mi humilde opinión.

En mi opinión, la respuesta es "Depende de cuánto tiempo tengas".Intento conseguir el 100% pero no me preocupo si no lo consigo con el tiempo que tengo.

Cuando escribo pruebas unitarias, uso un sombrero diferente al que uso cuando desarrollo código de producción.Pienso en lo que dice hacer el código probado y cuáles son las situaciones que pueden romperlo.

Normalmente sigo los siguientes criterios o reglas:

Que la prueba unitaria debería ser una forma de documentación sobre cuál es el comportamiento esperado de mis códigos, es decir.el resultado esperado dada una determinada entrada y las excepciones que puede generar y que los clientes pueden querer detectar (¿Qué deben saber los usuarios de mi código?)
Que la prueba unitaria debería ayudarme a descubrir condiciones hipotéticas en las que quizás aún no haya pensado.(¿Cómo hacer que mi código sea estable y robusto?)

Si estas dos reglas no producen una cobertura del 100%, que así sea.Pero una vez que tengo tiempo, analizo los bloques y líneas descubiertos y determino si todavía hay casos de prueba sin pruebas unitarias o si el código necesita ser refactorizado para eliminar los códigos innecesarios.

Depende en gran medida de su aplicación.Por ejemplo, algunas aplicaciones constan principalmente de código GUI que no se puede probar unitariamente.

No creo que pueda existir una regla de B/N.
Se debe revisar el código, con especial atención a los detalles críticos.
Sin embargo, si no se ha probado, ¡tiene un error!

Respuesta corta:60-80%

Respuesta larga:Creo que depende totalmente de la naturaleza de tu proyecto.Normalmente comienzo un proyecto probando unitariamente cada pieza práctica.Para el primer "lanzamiento" del proyecto, debería tener un porcentaje base bastante bueno según el tipo de programación que esté realizando.En ese punto, puede comenzar a "imponer" una cobertura mínima de código.

Dependiendo de la importancia del código, entre 75% y 85% es una buena regla general.El código de envío definitivamente debe probarse más a fondo que los servicios públicos internos, etc.

Esto debe depender de la fase del ciclo de vida de desarrollo de su aplicación en la que se encuentre.

Si ha estado en desarrollo por un tiempo y ya tiene una gran cantidad de código implementado y ahora se está dando cuenta de que necesita pensar en la cobertura del código, entonces debe verificar su cobertura actual (si existe) y luego usar esa línea de base para establecer hitos en cada sprint (o un aumento promedio durante un período de sprints), lo que significa asumir deuda de código mientras continúa brindando valor al usuario final (al menos en mi experiencia, al usuario final no le importa en lo más mínimo si ha aumentado las pruebas). cobertura si no ven nuevas funciones).

Dependiendo de su dominio, no es descabellado apuntar al 95%, pero debo decir que, en promedio, verá un caso promedio del 85% al 90%.

Creo que el mejor síntoma de una cobertura de código correcta es que la cantidad de problemas concretos que las pruebas unitarias ayudan a solucionar corresponde razonablemente al tamaño del código de pruebas unitarias que usted creó.

Creo que lo más importante es saber cuál es la tendencia de la cobertura a lo largo del tiempo y comprender las razones de los cambios en la tendencia.Si considera que los cambios en la tendencia son buenos o malos dependerá de su análisis del motivo.

Nuestro objetivo era >80% hasta hace unos días, pero después de usar una gran cantidad de código generado, no nos importa el porcentaje de edad, sino que hacemos que el revisor atienda la cobertura requerida.

Según la publicación de Testivus, creo que el contexto de respuesta debería ser el segundo programador.Dicho esto, desde un punto de vista práctico, necesitamos parámetros/objetivos por los que luchar.Considero que esto se puede "probar" en un proceso Agile analizando el código que tenemos, la arquitectura, la funcionalidad (historias de usuario), y luego sacar un número.Según mi experiencia en el área de telecomunicaciones, diría que el 60% es un buen valor para verificar.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow