unit-testing - software - pruebas unitarias php

¿Qué es un% de cobertura de código razonable para pruebas de unidad(y por qué)? (30)

Si tuviera que exigir un porcentaje mínimo de cobertura de código para las pruebas unitarias, tal vez incluso como un requisito para comprometerse con un repositorio, ¿cuál sería?

Por favor, explica cómo llegaste a tu respuesta (ya que si lo único que hiciste fue elegir un número, podría haberlo hecho yo solo).

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

Probablemente hubiera elegido una variedad de barras superiores para los criterios de envío, dependiendo de la criticidad de los subsistemas / componentes que se están probando.

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 al tamaño del código de pruebas unitarias que creó.

Creo que lo más importante 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 considera que los cambios en la tendencia son buenos o malos, dependerá de su análisis de la razón.

Cuando creo que mi código no se ha probado lo suficiente en la 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 de unidad, sé que esta prueba de unidad vale algo.

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

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.

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

Desde la publicación de 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 se puede "probar" en un proceso Agile al analizar el código que tenemos en la arquitectura, la funcionalidad (historias de usuario) y luego dar con un número. Según mi experiencia en el área de telecomunicaciones, diría que el 60% es un buen valor para verificar.

Echa un vistazo a Crap4j . Es un enfoque ligeramente más sofisticado que la cobertura de código directo. Combina las mediciones de cobertura de código con las mediciones de complejidad, y luego le muestra qué código complejo no se está probando actualmente.

En general, de los diversos documentos de mejores prácticas de excelencia en ingeniería que he leído, el 80% para el nuevo código en pruebas unitarias es el punto que produce el mejor rendimiento. Superando ese porcentaje de CC, se obtiene 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 para las empresas, por lo que no hay ninguna literatura pública que pueda señalarle.

En mi opinión, la respuesta es "Depende de cuánto tiempo tengas". Intento alcanzar 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 el código de producción. Pienso en lo que dice el código probado y en cuáles son las situaciones que pueden romperlo.

Normalmente sigo los siguientes criterios o reglas:

Que la prueba de unidad 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 determinada entrada y las excepciones que puede generar que los clientes quieran capturar (¿Qué deben saber los usuarios de mi código?)
Que la prueba de la unidad me ayude a descubrir las condiciones que podrían surgir y que aún no he pensado. (¿Cómo hacer mi código estable y robusto?)

Si estas dos reglas no producen una cobertura del 100%, que así sea. Pero una vez, 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 debe ser refactorizado para eliminar los códigos innecesarios.

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 en cobertura de prueba
Una mañana temprano, un programador le preguntó al gran maestro:
“Estoy listo para escribir algunas pruebas unitarias. ¿A qué código de cobertura debería aspirar?
El gran maestro respondió:
"No te preocupes por la cobertura, solo escribe 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 puedo decirte? Depende de cuánta gente necesite alimentar, cuánta hambre tienen, qué otros alimentos están 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, un tercer programador vino y le hizo la misma pregunta sobre la cobertura del código.
"¡Ochenta por ciento y no menos!" Replico 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 escuché que usted responde 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, el gran maestro comenzó a responder:
“El primer programador es nuevo y recién comienza con las pruebas. Ahora mismo tiene un montón de código y no hay pruebas. Él tiene un largo camino por recorrer; Enfocarse en la cobertura del código en este momento sería deprimente e inútil. Es mejor que se acostumbre a escribir y realizar algunas pruebas. Él 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 respondí preguntándole cuántos granos de arroz debía poner en una olla, la ayudé a darme 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 una respuesta simple, 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, ¿por qué respondiste al tercer programador ''Ochenta por ciento y no 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 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 tomar su té en un silencio contemplativo.

Esto debe depender de en qué fase del ciclo de vida de desarrollo de su aplicación se encuentra.

Si ha estado en desarrollo por un tiempo y ya tiene un montón de código implementado y ahora se está dando cuenta de que necesita pensar en la cobertura del código, 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 una deuda de código mientras continúa brindando valor al usuario final (al menos en mi experiencia, al usuario final no le importa ni un poco si aumenta la prueba) cobertura si no ven nuevas funcionalidades).

Dependiendo de tu dominio, no es irrazonable disparar para el 95%, pero tengo que decir que en promedio vas a estar viendo un caso promedio de 85% a 90%.

La cobertura de código es una métrica engañosa si su objetivo es la cobertura del 100% (en lugar del 100% de pruebas de todas las funciones).

Usted podría obtener un 100% al golpear 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 esas líneas son afectadas.
No pudo obtener un 100%, pero aún así ha probado todas sus rutas de código usadas al 80% / frecuencia. Tener pruebas que prueben cada ''lanzamiento de ExceptionTypeX'' o protección de programación defensiva similar que haya puesto es un ''bueno tener'' no un ''debe tener''

Así que confíe en usted o en sus desarrolladores para ser exhaustivo y cubrir todos los caminos a través de su código. Sea pragmático y no persiga la cobertura mágica al 100%. Si realiza un TDD de su código, debe obtener una cobertura del 90% + como bonificación. Use la cobertura de código para resaltar los trozos de código que ha perdido (no debería suceder si TDD, sin embargo, ya que solo escribe el código para hacer una prueba. No puede existir ningún código 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 una de las líneas que escribo. Pero sí creo en escribir el 100% de la cobertura de prueba de toda la funcionalidad que deseo proporcionar (incluso para las funciones extraordinarias que vine conmigo mismo y que no se discutieron durante las reuniones).

No me importa si tuviera un código que no esté cubierto en las pruebas, pero me importaría si lo refactorizaría y terminaría teniendo un comportamiento diferente. Por lo tanto, la cobertura de funcionalidad 100% es mi único objetivo.

La cobertura del código es excelente, pero solo en la medida en que los beneficios que obtiene de ella superen el costo / esfuerzo de lograrlo.

Hemos estado trabajando a un estándar del 80% durante algún tiempo, sin embargo, acabamos de tomar la decisión de abandonar esto y, en cambio, estar más concentrados en nuestras pruebas. Concentrándose en la lógica de negocios compleja, 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 de unidades existentes. Sentimos que habíamos llegado al punto en que el beneficio que estábamos obteniendo de nuestra cobertura de código se consideraba menor que el esfuerzo que teníamos que hacer para lograrlo.

La cobertura del código es solo otra métrica. En sí mismo, puede ser muy engañoso (consulte 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 que prueba todos los escenarios relevantes de su aplicación.

La respuesta aceptada es 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. En mi opinión, donde la respuesta aceptada no es suficiente, es cuando describe cómo se puede tomar esa decisión para un proyecto determinado.

Voy a tomar una oportunidad para hacerlo. No soy un experto en ingeniería de pruebas y me complacería ver una respuesta más informada.

Cuándo establecer los requisitos de cobertura del código

Primero, ¿por qué querrías imponer tal estándar en primer lugar? En general, cuando quiera introducir confianza empírica en su proceso. ¿Qué quiero decir con "confianza empírica"? Bueno, la verdadera corrección de objetivos. Para la mayoría de los programas, 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 conocible, pero sigue siendo un estándar subjetivo: siempre estará abierto para debatir si lo ha cumplido o no. Esos debates son útiles y deberían ocurrir, pero también exponen la incertidumbre.

La cobertura del código es una medida objetiva: una vez que vea su informe de cobertura, no hay ambigüedad sobre si las normas se han cumplido son útiles. ¿Prueba la corrección? No, en absoluto, pero tiene una relación clara 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 del código es una aproximación medible de las cualidades inconmensurables que nos interesan.

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

Para satisfacer a los interesados. Para muchos proyectos, hay varios actores que tienen un interés en la calidad del software que puede no estar involucrado en el desarrollo diario del software (gerentes, líderes técnicos, etc.) diciendo "vamos a escribir todo el las pruebas que realmente necesitamos "no son convincentes: necesitan confiar por completo o verificar con una estrecha supervisión en curso (asumiendo que incluso tienen la comprensión técnica para hacerlo). Proporcionar estándares medibles 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á trabajando en un equipo en el que varias personas están escribiendo códigos 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 se reconcilia esto? Encuentre una métrica en la que todos puedan estar de acuerdo y acéptelo como una aproximación razonable. Esto es especialmente útil (pero no exclusivamente) en equipos grandes, donde los prospectos 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 eres el único desarrollador y el único actor para tu proyecto, puedes tener ciertas cualidades en mente para el software. En lugar de realizar evaluaciones subjetivas continuas acerca de qué tan bien probado está el software (lo cual requiere trabajo), puede usar la cobertura de 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 sola métrica; Hay varias formas diferentes de medir la cobertura. Sobre cuál de ellos puede establecer un estándar depende de 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 la declaración : ¿Qué porcentaje de declaraciones se han ejecutado durante la prueba? Útil para tener una idea de la cobertura física de su código: ¿Qué parte del código que he escrito lo he probado?
- Este tipo de cobertura admite 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 asegurarse de 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 es probablemente suficiente.
Cobertura de sucursales : cuando hay una lógica de ramificación (por ejemplo, un if ), ¿se han evaluado ambas ramificaciones? Esto le da una mejor idea de la cobertura lógica de su código: ¿Cuántas de las rutas posibles que puede tomar mi código me han probado?
- Este tipo de cobertura es un indicador mucho mejor de que un programa ha sido probado en un conjunto integral de entradas. Si está utilizando la cobertura de códigos como su mejor aproximación empírica para tener confianza en la corrección, debe establecer estándares basados en la cobertura de sucursales o similares.

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 es similar a la cobertura de rama, pero reflejan una vista más detallada de las posibles permutaciones de Ejecución del programa que pueda encontrar.)

¿Qué porcentaje requerir?

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

Es de esperar que en este punto quede claro que estamos hablando de una aproximación, por lo que cualquier número que escojamos será intrínsecamente aproximado.

Algunos números que uno podría elegir:

100% . Puede elegir esto porque quiere estar seguro de que todo está probado. Esto no le da una idea de la calidad de la prueba, pero le dice que alguna prueba de calidad ha tocado cada declaración (o rama, etc.). Una vez más, esto vuelve a tener un grado de confianza: si su cobertura es inferior al 100% , sabes que algún subconjunto de tu código no ha sido probado.
- Algunos pueden argumentar que esto es una tontería, y solo debes probar las partes de tu 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 la década de los noventa). Adecuado en los casos en los que desee transmitir un nivel de confianza similar al 100%, pero deje un margen para no preocuparse por la esquina ocasional de prueba. código.
80% . He visto este número en uso varias veces, y no sé por completo 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ía de su código está probado. (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 ). Esto es apropiado para los casos medios donde "bien probado" no es una prioridad alta (usted no lo hace) No quiero gastar esfuerzos en pruebas de bajo valor, pero es una prioridad suficiente como para que aún 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 resulta difícil imaginar un caso en el que uno podría establecerlos. 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 nuevamente, la idea es hacer la elección subjetiva una vez que establezca el estándar y luego usar una medida objetiva en el futuro).

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 capacidad de mantenimiento, es probable que le interese el acoplamiento suelto, que se puede demostrar mediante la capacidad de prueba, que a su vez se puede medir (de cierta manera) mediante la cobertura del código. Por lo tanto, su estándar de cobertura de código proporciona una base empírica para aproximar la calidad de "capacidad de mantenimiento" también.

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

El proceso subyacente es:

Escribo mis pruebas para ejercitar toda la funcionalidad y los casos límite que se me ocurren (normalmente, a partir de la documentación).
Ejecuto las herramientas de cobertura de código.
Examino cualquier línea o camino no cubierto y cualquiera que considere no importante o inalcanzable (debido a la programación defensiva) que marque como no contando
Escribo nuevas pruebas para cubrir las líneas faltantes y mejorar la documentación si no se mencionan esos casos de borde.

De esta manera, si yo y mis colaboradores agregamos un nuevo código 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 lidiar con diferentes prioridades de prueba.

Mi respuesta a este dilema 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 verificar visualmente ( debo automatizar esto algún día) que app1 tiene una cobertura del 100% y app2 tiene 0% de cobertura.

Cuando / si 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 alcanzar el 100% de cobertura de línea del código de la biblioteca.

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

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

Con python, debería poder diseñar una prueba de humo que pudiera ejecutar automáticamente mi aplicación mientras mide la cobertura y, con suerte, obtener un balance general del 100% al combinar la prueba de humo con cifras de prueba de unidad.

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

En el mundo .Net, la gente suele citar al 80% como razonable. Pero dicen esto a nivel de solución. Prefiero medir a nivel de proyecto: el 30% podría estar bien para el proyecto de UI si tiene Selenium, etc. o pruebas manuales, el 20% para el proyecto de capa de datos podría estar bien, pero el 95% + podría ser bastante asequible para el negocio Reglas de capa, si no del todo necesarias. Entonces, la cobertura general puede ser, digamos, del 60%, pero la lógica crítica del negocio puede ser mucho más alta.

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

Línea inferior: aplique la regla 80:20 y deje que el número de errores de su aplicación lo guíe.

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

Nos dirigimos a más del 80% hasta hace pocos días, pero después de que usamos una gran cantidad de códigos generados, no nos importa el% de edad, sino que hacemos que el revisor reciba una llamada sobre la cobertura requerida.

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 verificables 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 son iguales a la lógica probada y no se debe leer demasiado en el porcentaje.

Es cierto, pero hay algunos puntos importantes que deben hacerse 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 un 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 circuito de retroalimentación más corto es bastante flexible, y abarca desde pruebas de clase hasta señalización entre procesos. La prueba de un subproducto entregable suele durar 5 minutos y para un bucle de retroalimentación tan corto es posible utilizar 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.

Cuando utilice la métrica de cobertura de código, no solo debe tener un porcentaje fijo (arbitrario) que deba cumplirse. Hacer esto no le brinda los beneficios reales del análisis de cobertura de código en mi opinión. En su lugar, define 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

El nuevo código solo se puede agregar si no superamos el LWM y no lo hacemos por debajo del HWM. En otras palabras, no se permite que disminuya la cobertura del código y se debe cubrir el nuevo código. Observe cómo digo que debo y no debo (explicado a continuación).

Pero, ¿no significa esto que será imposible limpiar la basura vieja y bien probada para la cual ya no tiene uso? Sí, y es por eso que tienes que ser pragmático sobre estas cosas. Hay situaciones en las que se deben romper las reglas, pero para su típica integración diaria, me parece que estas métricas son bastante útiles. Dan las siguientes dos implicaciones.

Se promueve el código comprobable. Al agregar un nuevo código, realmente tiene que hacer un esfuerzo para hacer que el código sea verificable, ya que tendrá que intentar cubrirlo todo con sus casos de prueba. El código comprobable suele ser bueno.
La cobertura de prueba para el código heredado está aumentando con el tiempo. Al agregar un nuevo código y no poder cubrirlo con un caso de prueba, se puede tratar de cubrir un código heredado para evitar la regla LWM. Esta trampa, a veces necesaria, al menos da el efecto secundario positivo de que la cobertura del 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 nuevamente, si el bucle de retroalimentación es demasiado largo, puede ser completamente imprá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 del 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). Los problemas encontrados durante el análisis de código dinámico (por herramientas como la familia de purificación, http://www-03.ibm.com/software/products/en/rational-purify-family ) son cosas como lecturas de memoria sin inicializar (UMR), pérdidas 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 generalmente son los casos anormales en el sistema, pero si desea que el sistema falle correctamente (es decir, la traza de error en lugar de un fallo) puede hacer un esfuerzo para cubrir los casos anormales. en el análisis de código dinámico también. Con solo un poco de mala suerte, una UMR puede llevar a una falta de seguridad o algo peor.
Las personas se enorgullecen de mantener el 100% para el nuevo código, y las personas discuten 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 trataría de tratar este caso anormal, etc.?

Y un negativo, por completo.

En un proyecto grande con muchos desarrolladores involucrados, todo el mundo no va a ser un genio de las pruebas con seguridad. Algunas personas tienden a usar la métrica de cobertura de código como prueba de que el código se probó 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 agradables si se usa correctamente, pero si se usa incorrectamente, de hecho puede llevar 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 bloquearse.

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 el 100% de la cobertura que el 90 por ciento de la cobertura. Es decir, es mucho más fácil llenar los vacíos de cobertura a medida que aparecen (y cuando se realizan los pozos de TDD, los vacíos de cobertura son raros y, por lo general, vale la pena) que administrar una lista de vacíos de cobertura a los que no ha llegado y que se perdió. 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 ha valido la pena hacerlo, pero nunca me ha resultado práctico volver atrás y cubrir todas las brechas de cobertura, porque el código antiguo no probado no se comprende lo suficiente como para hacerlo correctamente. con rapidez.

Respuesta corta: 60-80%

Respuesta larga: creo que depende totalmente de la naturaleza de su proyecto. Normalmente comienzo un proyecto por unidad probando cada pieza práctica. Para el primer "lanzamiento" del proyecto, debe tener un porcentaje base bastante bueno en función del tipo de programación que esté realizando. En ese momento, puede comenzar a "aplicar" una cobertura de código mínima.

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 concentrarse 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 en un facsímil razonable del mismo), debe 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. Todos los cuales son buenos para examinar.

¡Buena suerte!

Si ha estado haciendo pruebas de unidad durante un período de 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 el código escrito en el proyecto (excluye marcos, complementos, etc.) y tal vez incluso excluir ciertas clases compuestas completamente de código escrito de llamadas a código externo. Este tipo de llamada debe ser burlado / aplastado.

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

Tenemos un gran proyecto en el que, a través de Twitter, noté que, con 700 pruebas de unidad, 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 que más golpean sus usuarios? Puede agregar 50 pruebas más y solo agregar 2%.

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

Utilizo la cobertura, y cualquiera que sea el porcentaje, recomendaría mantener actualizados los valores de la tarea de verificación de cobertura. Como mínimo, continúe elevando el límite total y la tasa de crecimiento total a un nivel inferior a su cobertura actual, pero nunca baje esos valores. También vincule la propiedad de falla de compilación de Ant a esta tarea. Si la compilación falla debido a la falta de cobertura, 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" />

Visualización de la cobertura desde otra perspectiva: el código bien escrito con un claro flujo de control 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 el código teniendo en cuenta la claridad y la capacidad de cobertura, y al escribir las pruebas unitarias en paralelo con el código, obtendrá los mejores resultados en mi humilde opinión.