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

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 repository, ¿cuál sería?

Explique cómo llegó a su respuesta (ya que si todo lo que hacía era elegir un número, entonces podría haberlo hecho yo solo;)

Esta prosa de Alberto Savoia responde precisamente a esa pregunta (¡de una manera muy entretenida!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus en cobertura de prueba

Una mañana temprano, un progtwigdor 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 progtwigdor sonrió, se inclinó y se fue.

Más tarde ese día, un segundo progtwigdor hizo la misma pregunta.

El gran maestro señaló una olla de agua hirviendo y dijo:

“¿Cuántos granos de arroz debería poner en esa olla?”

El progtwigdor, mirando perplejo, respondió:

“¿Cómo puedo decírtelo? Depende de cuántas personas necesites alimentar, de qué tan hambrientas estén, qué otro alimento estés sirviendo, cuánto arroz tengas disponible, y así sucesivamente “.

“Exactamente”, dijo el gran maestro.

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

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

“¡El ochenta por ciento y nada menos!”, Respondió el maestro con voz severa, golpeando su puño sobre la mesa.

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

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

“Gran maestro, hoy te escuché responder la misma pregunta sobre la cobertura del código con tres respuestas diferentes. ¿Por qué?”

El gran maestro se levantó de su silla:

“Ven a tomar un té fresco conmigo y hablemos de eso”.

Después de llenar sus tazas con té verde humeante, el gran maestro comenzó a responder:

“El primer progtwigdor es nuevo y acaba de comenzar con las pruebas. Ahora mismo tiene mucho código y no hay pruebas. Él tiene un largo camino por recorrer; centrarse en la cobertura del código en este momento sería deprimente y bastante inútil. Es mejor que se acostumbre a escribir y ejecutar algunas pruebas. Él puede preocuparse por la cobertura más tarde “.

“El segundo progtwigdor, por otro lado, es bastante experiencia tanto en progtwigción como en pruebas. Cuando respondí preguntándole cuántos granos de arroz debería poner en una olla, la ayudé a darme cuenta de que la cantidad de pruebas necesarias depende de una serie de factores, y ella conoce esos factores mejor que yo: es su código después de todo . No hay una respuesta única y simple, y ella es lo suficientemente inteligente como para manejar la verdad y trabajar con eso “.

“Ya veo”, dijo el joven aprendiz, “pero si no hay una única respuesta simple, ¿por qué respondiste al tercer progtwigdor ‘Ochenta por ciento y nada menos’?”

El gran maestro se rió tan fuerte y ruidoso que su barriga, evidencia de que bebió más que solo té verde, se dejó caer de arriba abajo.

“El tercer progtwigdor solo quiere respuestas simples, incluso cuando no hay respuestas simples … y luego no las sigue de todos modos”.

El joven aprendiz y el gran maestro canoso terminaron de beber su té en silencio contemplativo.

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

  • Puedes obtener un 100% golpeando todas las líneas una vez. Sin embargo, aún podría perder la oportunidad de probar una secuencia particular (ruta lógica) en la que se golpean esas líneas.
  • No puede obtener un 100% pero todavía ha probado todas las rutas de código utilizadas al 80% / frecuencia. Tener pruebas que prueben cada ‘throw ExceptionTypeX’ o protector de progtwigción defensivo similar que hayas puesto es ‘bueno tener’ no ‘debe tener’

Por lo tanto, confíe en usted mismo o en sus desarrolladores para que sean minuciosos y cubran todos los caminos a través de su código. Sea pragmático y no persiga la cobertura mágica del 100%. Si TDD tu código, deberías obtener una cobertura del 90% + como bonificación. Use la cobertura de código para resaltar los trozos de código que ha perdido (sin embargo, esto no debería suceder si usa TDD … ya que solo escribe código para hacer una prueba, ningún código puede existir sin su prueba de socio).

La cobertura del código es excelente, pero la cobertura de funcionalidad es incluso mejor. No creo en cubrir cada línea que escribo. Pero sí creo en escribir una cobertura del 100% de las pruebas de todas las funcionalidades que deseo proporcionar (incluso para las funciones extra interesantes que obtuve y que no fueron discutidas durante las reuniones).

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

La respuesta aceptada es buena: no hay un solo número que tenga sentido como estándar para cada proyecto. Hay proyectos que simplemente no necesitan ese estándar. Donde la respuesta aceptada es insuficiente, en mi opinión, consiste en describir cómo se podría tomar esa decisión para un proyecto determinado.

Voy a intentarlo. No soy un experto en ingeniería de pruebas y estaría feliz de ver una respuesta más informada.

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

Primero, ¿por qué querrías imponer ese estándar en primer lugar? En general, cuando desea introducir confianza empírica en su proceso. ¿Qué quiero decir con “confianza empírica”? Bueno, la corrección de la meta real. 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 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 los estándares se han cumplido o no. ¿Prueba la corrección? No del todo, pero tiene una relación clara con lo bien probado que es el código, que a su vez es nuestra mejor forma de boost 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 tener un estándar empírico podría agregar valor:

  • Para satisfacer a los interesados. Para muchos proyectos, hay varios actores interesados ​​en la calidad del software que pueden no estar involucrados en el desarrollo diario del software (gerentes, clientes potenciales técnicos, etc.) diciendo “vamos a escribir todo el las pruebas que realmente necesitamos “no son convincentes: o bien deben confiar por completo o verificar con supervisión cercana continua (suponiendo que tengan el conocimiento técnico para hacerlo). Proporcionar estándares mensurables y explicar cómo se aproximan razonablemente a los objectives reales es mejor.
  • Para normalizar el comportamiento del equipo. Dejando a un lado las partes interesadas, si trabajas en un equipo en el que varias personas escriben código y pruebas, hay espacio para la ambigüedad de lo que califica como “bien probado”. ¿Todos tus colegas tienen la misma idea de qué nivel de prueba es suficientemente bueno? Probablemente no. ¿Cómo concilias esto? Encuentre una métrica en la que todos puedan estar de acuerdo y acéptela como una aproximación razonable. Esto es especialmente (pero no exclusivamente) útil en equipos grandes, donde los clientes potenciales pueden no tener 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 usted es el único desarrollador y ú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 cual requiere trabajo), puede usar la cobertura del código como una aproximación razonable y dejar que las máquinas lo midan por usted.

Qué métricas usar

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

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

  • Cobertura de estado : ¿Qué porcentaje de estados se han ejecutado durante la prueba? Útil para tener una idea de la cobertura física de su código: ¿Cuánto 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 prueban (y no como un indicador de la calidad de la prueba más allá de eso), entonces la cobertura del enunciado probablemente sea suficiente.
  • Cobertura de la sucursal : cuando hay una lógica de bifurcación (por ejemplo, un if ), ¿se han evaluado ambas twigs? Esto le da una mejor idea de la cobertura lógica de su código: ¿Cuántas de las posibles rutas puede tomar mi código si lo he probado?
    • Este tipo de cobertura es un indicador mucho mejor de que un progtwig ha sido probado en un conjunto completo de entradas. Si utiliza 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 sucursal o similar.

Hay muchas otras métricas (la cobertura de línea es similar a la cobertura de enunciados, pero arroja diferentes resultados numéricos para enunciados de varias líneas, por ejemplo: cobertura condicional y cobertura de ruta es similar a la cobertura de twig, pero refleja una vista más detallada de las posibles permutaciones de ejecución del progtwig que pueda 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 elijamos va a 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 da ninguna idea de la calidad de la prueba, pero le indica que alguna prueba de cierta calidad ha tocado cada afirmación (o sucursal, etc.). De nuevo, esto vuelve al grado de confianza: si su cobertura es inferior al 100% , usted sabe que algún subconjunto de su código no ha sido probado.
    • Algunos podrían 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 debería 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 casos en los que desee transmitir un nivel de confianza similar al 100%, pero permítase un margen para no preocuparse por el rincón de difícil evaluación ocasional de código.
  • 80% . He visto este número en uso varias veces y no sé por completo de 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 de lo que la mayoría de la gente quiere decir ). Esto es apropiado para casos intermedios en los que “bien probado” no es una alta prioridad (no lo haces). quiero desperdiciar esfuerzos en pruebas de bajo valor), pero es suficiente una prioridad que aún te gustaría tener algún estándar establecido.

No he visto números por debajo del 80% en la práctica, y me cuesta imaginar un caso en el que uno los establezca. El papel de estos estándares es boost 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 una vez más, la idea es hacer una elección subjetiva una vez cuando estableces el estándar, y luego usar una medida objetiva en el futuro).

Otras notas

Lo anterior supone que la corrección es el objective. La cobertura del código es solo información; puede ser relevante para otros objectives. Por ejemplo, si le preocupa el mantenimiento, probablemente le interese el acoplamiento flexible, que puede demostrarse mediante la capacidad de prueba, que a su vez puede medirse (en determinadas modas) por 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 “capacidad de mantenimiento”.

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”, he terminado.

El proceso subyacente es:

  1. Escribo mis pruebas para ejercitar toda la funcionalidad y los casos extremos en los que puedo pensar (generalmente trabajando desde la documentación).
  2. Ejecuto las herramientas de cobertura de código
  3. Examino cualquier línea o camino no cubierto y cualquiera que considere no importante o inalcanzable (debido a una progtwigción defensiva) lo marque como sin contar
  4. Escribo nuevas pruebas para cubrir las líneas faltantes y mejorar la documentación si esos casos extremos no se mencionan.

De esta manera, si yo y mis colaboradores agregamos un nuevo código o si cambiamos las pruebas en el futuro, hay una línea shiny para decirnos 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.

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 una cobertura de código del 20% .

Scott Hanselman respondió con palabras de sabiduría :

¿Es el DERECHO 20%? ¿Es el 20% el que representa el código que más golpean tus usuarios? Puede agregar 50 pruebas más y solo agregar 2%.

De nuevo, vuelve a mi Testivus en la respuesta de cobertura del código . ¿Cuánto arroz deberías poner en la olla? Depende.

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

Probablemente elegí una variedad de barras más altas para los criterios de envío, dependiendo de la criticidad de los subsistemas / componentes que se prueban.

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 tiempo. 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 donde las API están expuestas a otro código.

Enfoque 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 eliminar.

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

Es cierto, pero hay algunos puntos importantes que hacer sobre la cobertura del código. En mi experiencia, esta métrica es bastante útil cuando se usa correctamente. Habiendo dicho eso, no he visto todos los sistemas y estoy seguro de que hay un montón de ellos en los que es difícil ver el análisis de cobertura de código agregando valor real. El código puede verse muy diferente y el scope 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 ciclo de retroalimentación más corto es bastante flexible y cubre todo, desde las pruebas de clase hasta la señalización entre procesos. Probar un subproducto entregado normalmente demora 5 minutos y para un ciclo de retroalimentación tan corto es posible utilizar los resultados de la prueba (y específicamente la métrica de cobertura del código que estamos viendo aquí) para rechazar o aceptar confirmaciones en el repository.

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 del análisis de cobertura de código en mi opinión. En su lugar, defina las siguientes métricas:

  • Marca de nivel bajo de agua (LWM), el número más bajo de líneas descubiertas jamás vistas 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 vamos por encima del LWM y no vamos por debajo del HWM. En otras palabras, no se permite que la cobertura del código disminuya y se debe cubrir el nuevo código. Observe cómo digo debe y no debe (se explica a continuación).

Pero, ¿no significa esto que será imposible limpiar viejos desechos bien probados que ya no te sirven? Sí, y es por eso que debes ser pragmático sobre estas cosas. Hay situaciones en las que deben romperse las reglas, pero para su típica integración diaria, mi experiencia es que estas métricas son bastante útiles. Dan las siguientes dos implicaciones.

  • El código testable es promovido. Al agregar un código nuevo, realmente debe esforzarse para que el código sea comprobable, ya que deberá tratar de cubrirlo todo con sus casos de prueba. El código testable suele ser algo 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, uno puede tratar de cubrir algún código heredado para evitar la regla de LWM. Esta trampa a veces necesaria da al menos el efecto positivo de que la cobertura del código heredado boostá 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, puede ser completamente poco práctico configurar algo así 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 dynamic (a diferencia del análisis estático, es decir, Lint). Los problemas encontrados durante el análisis de código dynamic (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 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 con elegancia (es decir, error en lugar de locking) es posible que desee poner un poco de esfuerzo en cubrir los casos anormales en el análisis de código dynamic también. Con un poco de mala suerte, un UMR puede conducir a un segfault o peor.

  • La gente se enorgullece de mantener el 100% del código nuevo, y las personas discuten 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 tratar de cubrir este caso anormal, etc.

Y un negativo, para completar.

  • En un gran proyecto con muchos desarrolladores involucrados, seguramente no todos serán genios de las pruebas. Algunas personas tienden a usar la métrica de cobertura de código como prueba de que el código se ha 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 buenos beneficios si se usa de forma adecuada, pero si se utiliza de manera incorrecta, de hecho puede llevar a pruebas erróneas. Además 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 se puede ejecutar sin colgar o colgar.

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

En el mundo de .Net, las personas a menudo citan el 80% como razonables. Pero lo dicen a nivel de solución. Prefiero medir a nivel de proyecto: 30% podría estar bien para el proyecto de UI si tienes 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 alcanzable para el negocio capa de reglas, si no es totalmente necesario. Entonces, la cobertura general puede ser, por ejemplo, 60%, pero la lógica comercial crítica puede ser mucho más alta.

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

En pocas palabras: aplique la regla 80:20 y deje que el recuento de errores de su aplicación lo guíe.

Utilizo cobertura, y cualquiera que sea el porcentaje, recomendaría mantener actualizados los valores en la tarea de verificación de cobertura. Como mínimo, siga aumentando totallinerate y totalbranchrate justo por debajo de su cobertura actual, pero nunca baje esos valores. También vincule la propiedad de falla de comstackción Ant a esta tarea. Si la comstackción falla debido a la falta de cobertura, conoces el código agregado de otra persona pero no lo ha probado. Ejemplo:

  

Cuando creo que mi código no está suficientemente probado por la unidad y no estoy seguro de qué probar a continuación, uso la cobertura para ayudarme a decidir qué probar luego.

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, 50% cubierto o 97% cubierto.

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

Si ha estado haciendo 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 el código escrito en el proyecto (excluye frameworks, complementos, etc.) e incluso puede excluir ciertas clases compuestas enteramente de código escrito de llamadas a código externo. Este tipo de llamada debe ser burlada / trozada.

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 pruebas unitarias es el punto que produce el mejor rendimiento. Por encima de eso, CC% produce una menor cantidad de defectos por la cantidad de esfuerzo ejercida. Esta es una mejor 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 publicaciones públicas a las que pueda recomendarle.

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

Hemos trabajado a un nivel 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. Concentrarse en la compleja lógica de negocios, etc.

Esta decisión fue tomada debido a la cantidad de tiempo que pasamos persiguiendo la cobertura de código y manteniendo las pruebas de unidades existentes. Sentimos que habíamos llegado al punto en que consideramos que el beneficio que recibíamos de nuestra cobertura de código era menor que el esfuerzo que tuvimos que realizar para lograrlo.

Mira Crap4j . Es un enfoque un poco más sofisticado que la cobertura de código directo. Combina medidas de cobertura de código con mediciones 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 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 cuando ejecuto pruebas unitarias calculo la cobertura de esas dos carpetas y comprobé visualmente ( debo automatizar esto algún día) que la aplicación1 tiene una cobertura del 100% y app2 tiene 0% de cobertura.

Cuando / si encuentro que estos números difieren del estándar I de investigación y alteran el diseño del código para que la cobertura cumpla con el estándar.

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

También de vez en cuando reviso app2 / para ver si puedo probar algún código allí, y si puedo moverlo a la aplicación1 /

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

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

Visualización de la cobertura desde otra perspectiva: un 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 con claridad y 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 tenga”. Intento alcanzar 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 comparado con el sombrero que uso al desarrollar el código de producción. Pienso en lo que el código probado afirma hacer y cuáles son las situaciones que pueden romperlo.

Por lo general, 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. el resultado esperado dado un cierto ingreso y las excepciones que puede arrojar que los clientes quieran atrapar (¿Qué deberían saber los usuarios de mi código?)

  2. Que la prueba unitaria debería ayudarme a descubrir qué pasaría si todavía no hubiera pensado en las condiciones. (¿Cómo hacer mi código estable y robusto?)

Si estas dos reglas no producen una cobertura del 100%, entonces 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 usa 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 objective del conjunto de pruebas automáticas en su conjunto.

Aparte de eso, la respuesta depende de su metodología, idioma y herramientas de pruebas 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 una cobertura del 100% que una cobertura del 90 por ciento. Es decir, es mucho más fácil llenar las brechas de cobertura a medida que aparecen (y al hacer bien las brechas de cobertura de TDD y por lo general vale la pena su tiempo) que gestionar una lista de brechas de cobertura que no ha logrado y omite cobertura regresiones debido a su fondo constante de código descubierto.

La respuesta también depende de la historia de tu proyecto. Solo he encontrado que lo anterior es práctico en proyectos administrados de esa manera desde el principio. He mejorado mucho la cobertura de los grandes proyectos heredados, y ha valido la pena hacerlo, pero nunca me ha parecido práctico volver atrás y llenar cada intervalo de cobertura, porque el código antiguo no probado no se entiende lo suficiente como para hacerlo correctamente y con rapidez.

Depende mucho de tu aplicación. Por ejemplo, algunas aplicaciones consisten principalmente en un código GUI que no se puede probar en unidades.

No creo que pueda haber una regla B / N tal.
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!

Respuesta corta: 60-80%

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

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

Esto tiene que depender de en qué fase del ciclo de vida de desarrollo de la aplicación se encuentre.

Si ha estado en desarrollo por un tiempo y ya tiene muchos códigos implementados 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 una subida promedio en un período de sprints), lo que significa asumir deuda de código mientras se continúa entregando valor para el usuario final (al menos en mi experiencia, al usuario final no le importa si ha aumentado la prueba cobertura si no ven nuevas características).

Dependiendo de su dominio, no es irrazonable disparar en un 95%, pero tendría que decir que en promedio verá un promedio de 85% a 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 corregir corresponde razonablemente al tamaño del código de pruebas unitarias que usted creó.

Creo que lo que puede importar más es saber cuál es la tendencia de cobertura en el tiempo y comprender las razones de los cambios en la tendencia. Si usted ve los cambios en la tendencia como buenos o malos dependerá de su análisis de la razón.

Teníamos como objective> 80% hasta hace unos días, pero después de usar mucho código generado, no nos importa el% de edad, sino que hacemos que el revisor haga una llamada sobre la cobertura requerida.

De la publicación de Testivus, creo que el contexto de respuesta debería ser el segundo progtwigdor. Habiendo dicho esto desde un punto de vista práctico, necesitamos parámetros / metas por las cuales esforzarnos. Considero que esto se puede “probar” en un proceso Ágil mediante el análisis del código que tenemos la architecture, la funcionalidad (historias de usuario) y luego se puede obtener un número. Según mi experiencia en el área de Telecom, diría que un 60% es un buen valor para verificar.

    Intereting Posts