La cobertura de código es una métrica engañosa si su objetivo es una cobertura del 100% (en lugar de una prueba del 100% de todas las características).

• Puedes obtener un 100% golpeando todas las líneas una vez. Sin embargo, todavía podría perderse probar una secuencia particular (ruta lógica) en la que se golpean esas líneas.
• No pudo obtener un 100%, pero todavía ha probado todas sus rutas de código 80%/freq usadas. Tener pruebas que prueben cada 'throw ExceptionTypeX' o guardia de programación defensiva similar que hayas puesto es un 'nice to have 'not a' must have '

Así que confía en ti mismo o en tus desarrolladores para que sean exhaustivos y cubran cada ruta a través de su código. Sea pragmático y no persiga la mágica cobertura del 100%. Si usted TDD su código usted debe obtener una cobertura del 90% + como un bono. Use la cobertura de código para resaltar fragmentos de código que se ha perdido (aunque no debería suceder si TDD.. ya que escribes código solo para pasar la prueba. Ningún código puede existir sin su prueba de socio. )

La cobertura de código es excelente, pero la cobertura de 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 toda la funcionalidad que quiero proporcionar (incluso para las características extra geniales que vine conmigo mismo y que no se discutieron durante las reuniones).

No me importa si me hubiera código que no está cubierto en las pruebas, pero me importaría si me gustaría rehacer mi código y al final tener un comportamiento diferente. Pues, la cobertura de funcionalidad del 100% es mi único objetivo.

La respuesta aceptada hace un buen punto - no hay un solo número que va a tener sentido como un 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 uno podría tomar esa decisión para un proyecto dado.

Voy a intentar hacerlo. No soy un experto en ingeniería de pruebas y me gustaría ver una respuesta más informada.

Cuándo establecer la cobertura del código requisitos

Primero, ¿por qué querrías imponer tal estándar en primer lugar? En general, cuando se quiere introducir la confianza empírica en su proceso. ¿Qué quiero decir con "confianza empírica"? Bueno, la verdadera meta corrección . 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 está bien probado. Esto es más cognoscible, pero sigue siendo un estándar subjetivo: Siempre estará abierto al debate si usted lo he conocido. Esos debates son útiles y deberían tener lugar, pero también ponen de manifiesto la incertidumbre.

La cobertura de código es una medida objetiva: Una vez que vea su informe de cobertura, no hay ambigüedad sobre si los estándares se han cumplido son útiles. ¿Demuestra lo correcto? En absoluto, pero tiene una clara relación con lo bien probado que está el código, que a su vez es nuestra mejor manera de aumentar la confianza en su corrección. La cobertura de código es una aproximación medible de inconmensurable cualidades que nos importan.

Algunos casos específicos donde tener un estándar empírico podría agregar valor:

• Para satisfacer a las partes interesadas. Para muchos proyectos, hay varios actores que tienen un interés en la calidad del software que pueden no estar involucrados en el desarrollo diario del software (gerentes, clientes potenciales técnicos, etc.).) Decir "vamos a escribir todas las pruebas que realmente necesitamos" no es convincente: O bien necesitan confiar por completo, o verificar con el cierre continuo supervisión (suponiendo que incluso tienen la comprensión técnica para hacerlo.) Proporcionar estándares mensurables y explicar cómo se aproximan razonablemente a los objetivos reales es mejor.
• Para normalizar el comportamiento del equipo. Aparte de las partes interesadas, si estás trabajando en un equipo donde varias personas están escribiendo 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 conciliar esto? Encuentre una métrica en la que todos estén de acuerdo y acéptela como una aproximación razonable. Esto es especialmente útil (pero no exclusivamente) en equipos grandes, donde los clientes potenciales pueden no tener supervisión directa sobre los desarrolladores junior, por ejemplo. Las redes de confianza también importan, pero sin mediciones objetivas, es fácil que el comportamiento grupal se vuelva inconsistente, incluso si todos actúan de buena fe.
• Para mantenerte honesto. Incluso si eres el único desarrollador y solo stakeholder para 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 usar la cobertura de código como una aproximación razonable y dejar que las máquinas la midan por usted.

Qué métricas usar

La cobertura de código no es una sola métrica; hay varias formas diferentes de medir la cobertura. En cuál de ellos se puede establecer un estándar depende de lo que estás usando ese estándar para satisfacer.

Usaré dos métricas comunes como ejemplos de cuándo puedes usarlas para establecer estándares:

• Cobertura de sentencias : ¿Qué porcentaje de sentencias se han ejecutado durante la prueba? Útil para tener una idea de lacobertura física de su código: ¿Cuánto del código que he escrito he probado realmente?
  • Este tipo de cobertura apoya 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 de código para garantizar que 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 ramas : Cuando hay lógica de ramificación (por ejemplo, un if), ¿se han evaluado ambas ramas? Esto da una mejor idea de lacobertura 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 mucho mejor indicador de que un programa ha sido probado a través de un conjunto completo de entradas. Si está utilizando la cobertura de código como su mejor aproximación empírica para la confianza 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 instrucciones, pero produce resultados numéricos diferentes para las instrucciones multilínea, por ejemplo; la cobertura condicional y la cobertura de ruta es similar a la rama cobertura, pero reflejan una vista más detallada de las posibles permutaciones de ejecución del programa que podría encontrar.)

Qué porcentaje requerir

Finalmente, volvamos a la pregunta original: Si establece estándares de cobertura de código, ¿cuál debería ser ese número?

Esperemos que esté claro en este punto que estamos hablando de una aproximación para empezar, por lo que cualquier número que elegimos va a ser inherentemente aproximado.

Algunos números que uno podría elija:

• 100%. Usted puede elegir esto porque quiere estar seguro de que todo está probado. Esto no te da ninguna idea de la calidad de la prueba, pero te dice que alguna prueba de alguna calidad ha tocado cada declaración (o rama, etc.). Una vez más, esto vuelve al grado de confianza: Si su cobertura está por debajo del 100%, sabe que algún subconjunto de su código no está probado.
  • Algunos podrían argumentar que esto es tonto, y 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%, otros números en los años noventa.) Apropiado en los casos en los que desea transmitir un nivel de confianza similar al 100%, pero deje algún margen para no preocuparse por la esquina de código difícil de probar ocasionalmente.
• 80%. He visto este número en uso un par de veces, y no sé completamente donde se origina. Yo creo que podría ser una extraña apropiación indebida de la regla 80-20; generalmente, la intención aquí es mostrar que la mayor parte de su código está probado. (Sí, el 51% también sería "la mayoría", pero el 80% es más reflejo de lo que la mayoría de la gente quiere decir por la mayoría.) Esto es apropiado para casos de terreno medio donde "bien probado" no es una prioridad alta( no desea desperdiciar esfuerzo en pruebas de bajo valor), pero es suficiente de una prioridad que todavía le gustaría 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 establecería. El papel de estos estándares es aumentar la confianza en la corrección, y los números por debajo del 80% no son particularmente inspiradores de confianza. (Sí, esto es subjetivo, pero de nuevo, la idea es hacer la elección subjetiva una vez cuando se establece el estándar, y luego utilizar una medición objetiva va adelante.)

Otras notas

Lo anterior asume que la corrección es la meta. La cobertura del código es solo información; puede ser relevante para otros objetivos. Por ejemplo, si le preocupa la mantenibilidad, probablemente le importe el acoplamiento suelto, que puede demostrarse mediante la capacidad de prueba, que a su vez puede medirse (de ciertas maneras) 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 "mantenibilidad".

Mi cobertura de código favorito 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", he terminado.

El proceso subyacente es:

1. Escribo mis pruebas para ejercitar toda la funcionalidad y los casos extremos que se me ocurren (generalmente trabajando a partir de la documentación).
2. Corro las herramientas de cobertura de código
3. Examino cualquier línea o ruta no cubierto y cualquiera que considere no importante o inalcanzable (debido a la programación defensiva) marca como no contando
4. Escribo nuevas pruebas para cubrir las líneas que faltan y mejorar la documentación si esos casos extremos no se mencionan.

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

Tendría otro anectode sobre la cobertura de la prueba que me gustaría compartir.

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

Scott Hanselman respondió con palabras de sabiduría:

¿Es el 20% CORRECTO? Es el 20% que representa el código de sus usuarios ¿golpear más? Podrías añadir 50 más pruebas y solo añadir 2%.

De nuevo, se remonta a mi Testivus en Cobertura de código Respuesta. ¿Cuánto arroz debe poner en la olla? Depende.

El 85% sería un buen punto de partida para los criterios de comprobación.

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

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

Centre sus esfuerzos de prueba en estas API. Asegúrese de que las API están 1) bien documentados y 2) tienen 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. Todos los cuales son buenos para investigar.

¡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 comprobables 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 uno no debe leer demasiado en el porcentaje.

Cierto, pero hay algunos puntos importantes que deben hacerse sobre la cobertura del código. En mi experiencia esta métrica es realmente muy útil, cuando se utiliza correctamente. Dicho esto, no he visto todos los sistemas y estoy seguro de que hay toneladas de ellos donde es difícil ver el análisis de cobertura de código que agrega algún valor real. El código puede parecer muy diferente y el alcance del marco de prueba disponible puede variar.

Además, mi razonamiento se refiere principalmente a bucles de retroalimentación de prueba bastante cortos. Para el producto que estoy desarrollando, el bucle de retroalimentación más corto es bastante flexible, cubriendo todo desde la clase pruebas de señalización interproceso. Probar un sub-producto entregable típicamente toma 5 minutos y para un bucle 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 usar la métrica de cobertura de código, no solo debe tener un porcentaje fijo (arbitrario) que debe cumplirse. Hacer esto no le da los beneficios reales de la cobertura de código análisis en mi opinión. En su lugar, defina las siguientes métricas:

• Marca de agua baja (LWM), el menor número de líneas descubiertas jamás visto en el sistema bajo prueba
• Marca de agua alta (HWM), el porcentaje de cobertura de código más alto jamás visto para el sistema bajo prueba

Solo se puede agregar nuevo código si no vamos por encima del LWM y no vamos por debajo del HWM. En otras palabras, la cobertura del código no puede disminuir, y el nuevo código debe estar cubierto. Noten cómo diga debería y no debe (explicado abajo).

¿Pero esto no significa que será imposible limpiar la basura vieja y bien probada que ya no tiene uso? Sí, y es por eso que tienes que ser pragmático sobre estas cosas. Hay situaciones en las que las reglas tienen que romperse, pero para su 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 añadir nuevo código realmente tienes que hacer un esfuerzo para que el código sea comprobable, porque tendrás que tratar de cubrirlo todo con tus casos de prueba. El código comprobable suele ser algo bueno.

• La cobertura de pruebas para el código heredado está aumentando con el tiempo. Al agregar código nuevo y no ser capaz de cubrirlo con un caso de prueba, uno puede tratar de cubrir algún código heredado en su lugar para evitar la regla LWM. Esto a veces es necesario hacer trampa al menos da el efecto secundario positivo que la cobertura de el código heredado aumentará con el tiempo, haciendo que la aplicación aparentemente estricta de estas reglas sea bastante pragmática en la práctica.

Y de nuevo, si el bucle de retroalimentación es demasiado largo, podría ser 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 estático, es decir, Lint). Problemas encontrados durante el análisis dinámico de código (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), fugas de memoria, etc. Estos problemas solo se pueden encontrar si el código está cubierto por un caso de prueba ejecutado. El código que es más difícil de cubrir en un caso de prueba es generalmente los casos anormales en el sistema, pero si desea que el sistema falle correctamente (es decir, trace de errores en su lugar de bloqueo) es posible que desee poner un poco de esfuerzo en la cobertura de los casos anormales en el análisis de código dinámico, así. Con solo un poco de mala suerte, un UMR puede conducir a un segfault o algo peor.

• La gente se enorgullece de mantener el 100% para el nuevo código, y la gente discute los problemas de prueba con una pasión similar a otros problemas de implementación. ¿Cómo se puede escribir esta función de una manera más comprobable? ¿Cómo tratarías de cubrir este caso anormal?, sucesivamente.

Y un negativo, para completar.

• En un gran proyecto con muchos desarrolladores involucrados, todo el mundo no va a ser un genio de la prueba con seguridad. Algunas personas tienden a usar la métrica de cobertura de 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 darle algunos beneficios agradables si se usa correctamente, pero si se usa mal, de hecho, puede conducir a malas pruebas. 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 o estrellarse.

Muchas tiendas no valoran las pruebas, por lo que si está por encima de cero, al menos hay alguna apreciación del valor, por lo que podría decirse que no es cero, ya que muchos siguen siendo cero.

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

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

En pocas palabras: Aplica la regla 80:20 y deja que el conteo de errores de tu aplicación te guíe.

Utilizo cobertura, y cualquiera que sea el porcentaje, recomendaría mantener los valores en la tarea cobertura-check actualizados. Como mínimo, seguir subiendo totallinerate y totalbranchrate justo debajo de su cobertura actual, pero nunca a bajar esos valores. También vincule la propiedad Ant build failure a esta tarea. Si la compilación falla debido a la falta de cobertura, conoces el código agregado de alguien pero no lo has probado. Ejemplo:

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

Cuando creo que mi código no está suficientemente probado por unidad, y no estoy seguro de qué probar a continuación, uso 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 a código que no está cubierto, 50% cubierto o 97% cubierto.

La cobertura de código es solo otra métrica. En sí mismo, puede ser muy engañoso (ver www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated ). 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 has estado haciendo pruebas unitarias por una cantidad decente de tiempo, 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 es nuevo en las pruebas.

Este número solo debe incluir el código escrito en el proyecto (excluye frameworks, plugins, etc.) y tal vez incluso excluir ciertas clases compuestas enteramente de código escrito de llamadas a código externo. Este tipo de llamada debe ser burlado/apagado.

En términos generales, de los varios documentos de mejores prácticas de excelencia en ingeniería que he leído, el 80% para el nuevo código en las pruebas unitarias es el punto que produce el mejor retorno. Ir por encima de ese CC % produce una menor cantidad de defectos por la cantidad de esfuerzo ejercido. Esta es una buena práctica que es utilizada por muchas grandes corporaciones.

Desafortunadamente, la mayoría de estos resultados son internos de las empresas, por lo que no hay literaturas públicas a las que pueda señalarles.

La cobertura de código es excelente, pero solo mientras los beneficios que obtiene 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 su lugar centrarnos más en nuestras pruebas. Concentrándose en la compleja lógica de negocio, etc.,

Esta decisión se tomó debido a la creciente cantidad de tiempo que pasamos persiguiendo la cobertura del código y manteniendo las pruebas unitarias existentes. Sentimos que teníamos llegamos al punto en que el beneficio que estábamos obteniendo de nuestra cobertura de código se consideró menor que el esfuerzo que tuvimos que poner para lograrlo.

Echa un vistazo Crap4j. Es un enfoque un poco más sofisticado que la cobertura de código directo. Combina mediciones de cobertura de código con mediciones de complejidad y, a continuación, 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 puede probar y una cobertura de línea del 0% del código que no puede probar.

Mi práctica actual en Python es dividir mis módulos .py en dos carpetas: app1/ y app2/ y al ejecutar pruebas unitarias calcular la cobertura de esas dos carpetas y comprobar visualmente (yo debo automatizar esto algún día) que app1 tiene 100% de cobertura y app2 tiene 0% de cobertura.

Cuando / si encuentro que estos números difieren del estándar I investigar y alterar el diseño del código para que la cobertura se ajuste a la norma.

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

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

Ahora no estoy demasiado preocupado por la cobertura agregada porque puede variar enormemente dependiendo del tamaño del proyecto, pero generalmente he visto 70% a más del 90%.

Con python, debería ser capaz de diseñar una prueba de humo que podría ejecutar automáticamente mi aplicación mientras mide la cobertura y, con suerte, obtener un aggreagate del 100% al combinar la prueba de humo con las cifras de unittest.

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

En mi opinión, la respuesta es "Depende de cuánto tiempo tengas". Trato de lograr el 100% pero no hago un escándalo si no lo consigo con el tiempo que tengo.

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

Normalmente sigo los siguientes criterios o reglas:

1. Que la Prueba Unitaria debe ser una forma de documentación sobre cuál es el comportamiento esperado de mis códigos, es decir. la salida esperada dada una cierta entrada y las excepciones que puede lanzar que los clientes pueden querer atrapar (¿Qué deben saber los usuarios de mi código?)

2. Que la Prueba Unitaria debería ayudarme a descubrir las condiciones de qué pasaría si aún no hubiera 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, tengo el 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.

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 debe 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 administrar la cobertura del 100% que 90 y algo por ciento de cobertura. Es decir, es mucho más fácil llenar los vacíos de cobertura a medida que aparecen (y al hacer bien TDD los vacíos de cobertura son raros y generalmente valen su tiempo) que administrar una lista de vacíos de cobertura a los que no ha llegado y omite las regresiones de cobertura debido a su fondo constante de código descubierto.

La respuesta también depende del historial de tu proyecto. Solo he encontrado que lo anterior es práctico en proyectos gestionados de esa manera desde el principio. He se ha mejorado mucho la cobertura de grandes proyectos heredados, y ha valido la pena hacerlo, pero nunca he encontrado práctico volver atrás y llenar cada brecha de cobertura, porque el código antiguo no probado no se entiende lo suficiente como para hacerlo correcta y rápidamente.

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

No creo que pueda haber tal regla B / N.
El código debe revisarse, prestando especial atención a los detalles críticos.
Sin embargo, si no ha sido probado, tiene un error!

Respuesta corta: 60-80%

Respuesta Larga: Creo que depende totalmente de la naturaleza de su proyecto. Normalmente comienzo un proyecto probando cada pieza práctica. Para la primera "versión" del proyecto, debe tener un porcentaje base bastante bueno basado en el tipo de programación que está haciendo. En ese punto, puede comenzar a" hacer cumplir " una cobertura de código mínimo.

Dependiendo de la criticidad del código, entre 75% y 85% es una buena regla general. Código de envío definitivamente debe ser probado más a fondo que en los servicios públicos de la casa, etc.

Esto tiene que 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 mucho código implementado y ahora se está dando cuenta de que necesita pensar en la cobertura de 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 la deuda de código mientras continúa entregando valor de usuario (al menos en mi experiencia al usuario final no le importa un poco si has aumentado la cobertura de prueba si no ven nuevas características).

Dependiendo de su dominio, no es irrazonable disparar al 95%, pero tendría que decir que, en promedio, verá un caso promedio del 85% al 90%.

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

Creo que lo que más importa es saber cuál es la tendencia de cobertura a lo largo del tiempo y comprender las razones de los cambios en la tendencia. Si usted ve los cambios en la tendencia como bueno o malo dependerá de su análisis de la razón.

Nos enfocamos en >80% hasta hace unos días, pero después de usar mucho código Generado, no nos importa %age, sino que el revisor tome una llamada sobre la cobertura requerida.

De la publicación Testivus creo que el contexto de la 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 puede ser "probado" en un proceso Ágil mediante el análisis del código que tenemos la arquitectura, funcionalidad (historias de usuario), y luego llegar a un número. Basándome en mi experiencia en el área de Telecomunicaciones, diría que el 60% es una buena relación calidad-precio.