La cantidad de cobertura de código es “suficiente”?
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Estamos comenzando un impulso para la cobertura de código aquí en mi trabajo, y me tiene que pensar .... ¿Cuánta cobertura de código es suficiente?
Cuando se llega al punto de rendimientos decrecientes en la cobertura de código? ¿Cuál es el punto óptimo entre una buena cobertura y no es suficiente? ¿Varía según el tipo de proyecto que su están haciendo (es decir, WPF, WCF, móvil, ASP.NET) (Estos son C # clases estamos escribiendo.)
Solución
Nos dirigimos a al menos 70%. En cosas que son más fácilmente (estructuras de datos funcionales, por ejemplo) comprobables, nuestro objetivo es el 90% y la mayoría de los individuos objetivo de lo más cercano a 100% como sea posible. En lo relacionado con WPF y otros marcos que son muy difíciles de probar, se obtiene una cobertura mucho menor (casi 70%).
Otros consejos
Soy de la opinión de que la cobertura de código por sí sola es un indicador pobre. Es fácil de producir toneladas de pruebas inútiles que portada el código, pero no verificar adecuadamente la salida, o no lo hacen casos extremos de prueba, por ejemplo. Cubriendo código sólo significa que no produce una excepción, no es que sea correcto. Es necesario calidad pruebas- la cantidad no es tan importante.
"suficiente" es cuando se puede realizar cambios en el código con la confianza de que no estás romper nada. En algunos proyectos, que podría ser del 10%, en otros, podría ser del 95%.
Es casi nunca es tan alto como 100%. Sin embargo, a veces tratando de obtener la cobertura de código 100% puede ser una gran manera de eliminar costra de la base de código. No olvide que hay dos maneras de aumentar la cobertura de código - de escritura más pruebas o para llevar a cabo código. Si el código no está cubierto porque es difícil de probar, hay una buena probabilidad de que puede simplificar o refactorizar para que sea más fácil de prueba. Si es demasiado oscuro para molestar a prueba, por lo general hay una oportunidad buena que ninguna otra cosa en el código está utilizando.
cobertura de código se acerca al 100% asintóticamente. En consecuencia, ese último 5% es probablemente más esfuerzo que vale la pena, a medida que comienza a alcanzar prácticamente nula rentabilidad para el esfuerzo realizado.
La cobertura es a métrica para mantener un ojo en, pero no debe ser el objetivo final. Que he visto (y es cierto que por escrito!) Un montón de código de alta cobertura - cobertura del 100% (TDD, por supuesto), sin embargo:
- insectos todavía surgen
- Diseño Todavía puede ser pobre
- que realmente puede matar a ti mismo tiro por alguna meta de cobertura arbitraria - escoger sus batallas: p
Hay un "Camino de Testivus" entrada que creo que es apropiado referencia aquí :)
20% de la mayoría del código se ejecutará el 80% del tiempo . Un análisis de la cobertura de código no es muy útil a menos que se combina con un gráfico de llamadas para determinar lo que necesita ser probado más. Eso te dice dónde están sus casos extremos es probable que sean. Es posible llegar a 100 pruebas sólo para esos casos extremos, que constituyen menos del 5% del código real.
Así, asegúrese de cubrir el 100% de la 20% que define caminos críticos, y al menos 50% del resto (de acuerdo con el gráfico de llamadas). Esto debe conseguir que (más o menos) 70% - 75% de cobertura total, pero que varía.
No queme el tiempo tratando de superar la cobertura total del 70%, dejando casos extremos críticos sin controles.
El uso de cobertura como una guía para indicar las áreas no probado. En lugar de tener un mandato para la cobertura es más prudente para entender la razón de código no están cubiertos. Grabación de una razón para el déficit es una buena disciplina que permite a los riesgos a equilibrarse.
A veces la razón es menos que deseable ', por ejemplo, se acabó el tiempo', pero podría estar bien para una pronta liberación. Es mejor zonas de marcas para volver a un aumento en la cobertura más adelante.
Yo trabajo en el software de vuelo crítico en el que se considera adecuada cobertura de declaración de 100% para los sistemas no críticos. Para los sistemas más críticos, comprobamos cobertura de sucursales / decisiones y utilizar una llamada técnica de MC / DC que a veces no es lo bastante rigurosa.
También tiene que asegurarse de que también hemos cubierto el código objeto.
Es un equilibrio entre el riesgo, en nuestro caso muy alta, contra el valor / costo. Se necesita una decisión informada sobre la base del riesgo de perder un error.
Al empezar a considerar los cambios que afectarían a correr el tiempo de rendimiento, seguridad, flexibilidad o capacidad de mantenimiento para permitir una mayor cobertura de código es el momento de poner fin a la búsqueda de una mayor cobertura de código.
Tengo proyectos en los que ese punto es 0% porque la cobertura es imposible calcular sin dañar el diseño y otros proyectos en los que es tan alto como 92%.
Código métricas de cobertura sólo son útiles en señalar eran que podría haber perdido algunas pruebas. Ellos le dicen nada acerca de la calidad de las pruebas.
software crítico requiere una cobertura espacial declaración de 100%.
Al principio no tiene sentido. Todo el mundo sabe que una cobertura de las pruebas no significa que el código está totalmente probado y que no es tan difícil de conseguir una cobertura del 100% sin llegar a probar la aplicación.
Sin embargo, la cobertura del 100% es un límite inferior: si bien la cobertura del 100% no es una prueba de un software libre de errores, lo cierto es que con una cobertura menor el código no se ha probado completamente y esto es simplemente inaceptable para el espacio crítico el software.
A mi me gusta @ respuesta de RevBingo porque sugiere que la lucha hacia 100% puede causar a limpiar o eliminar código no utilizado. Lo que no he visto en las otras respuestas es una sensación de cuando se necesita una alta cobertura y no cuando lo hace. Tomé una puñalada a partir de este. Creo que añadir detalles a una tabla como esta sería una actividad más útil que la búsqueda de número de cobertura una prueba que era correcto para todo el código.
100%
Para una API pública, como las colecciones de java.util, que no está acoplado a una base de datos y no vuelve HTML, creo que el 100% de cobertura es un objetivo noble de partida, incluso si te conformas con un 90-95% debido a tiempo o de otro tipo. El aumento de cobertura de la prueba después de que son características fuerzas completas un nivel más detallado de escrutinio que otros tipos de revisión de código. Si su API es en absoluto popular, la gente se utilizan, subclase, que deserializar, etc. de manera que no se puede esperar. Usted no quiere que su primera experiencia a ser encontrar un error, o la supervisión de diseño!
90%
Para el código de infraestructura de negocios, que se lleva en las estructuras de datos y estructuras de datos devuelve, 100% sigue siendo probablemente una buena partir meta, pero si este código no es suficiente público para invitar a una gran cantidad de mal uso, tal vez el 85% es todavía aceptable ?
75%
Para código que recibe y devuelve cadenas, creo que la unidad de pruebas es mucho más frágil, pero todavía puede ser útil en muchas situaciones.
50% o menos
No me gusta escribir pruebas para funciones que devuelven HTML porque es muy frágil. ¿Qué pasa si alguien cambia la CSS, JavaScript, o toda la masa de Inglés HTML y regresa no tiene sentido para los usuarios finales humanos? Si usted puede encontrar una función que utiliza una gran cantidad de lógica de negocio para producir un poco de HTML, esta prueba puede bien vale la pena. Pero la situación inversa puede no ser vale la pena probar en absoluto.
cerca de 0%
Por cierto código, la definición de "correcta" es "tenga sentido para el usuario final." Hay pruebas no tradicionales que se pueden realizar en contra de este código como la gramática de comprobación automatizado o HTML validación de la salida. Incluso me he preparado declaraciones grep para las pequeñas inconsistencias que comúnmente presa de en el trabajo, como decir "Iniciar sesión" cuando el resto del sistema lo llama, "Iniciar sesión". Este hombre no sea estrictamente una prueba de unidad, sino una manera útil a las cuestiones de captura sin esperar la salida específico.
En última instancia, sin embargo, solamente un ser humano puede juzgar lo que es sensible a los seres humanos. Prueba de la unidad no puede ayudarle allí. A veces se necesitan varios seres humanos para juzgar que la precisión.
Absolute 0%
Esta es una categoría triste y me siento como menos de una persona por escribirlo. Pero en cualquier proyecto suficientemente grande que hay agujeros de conejo que puede aspirar personas-semanas de tiempo sin proporcionar ningún beneficio comercial.
He comprado un libro, ya que afirmaba mostrar cómo los datos de forma automática simuladas para pruebas de hibernación. Pero únicamente evaluó consultas Hibernate HQL y SQL. Si tiene que hacer un montón de HQL y SQL, que realmente no está recibiendo la ventaja de Hibernate. Hay una forma de hibernación de base de datos en memoria, pero no han invertido el tiempo para encontrar la manera de utilizarla de manera eficaz en las pruebas. Si tuviera que correr, yo quiero tener alta (50% -100%) cobertura de la prueba para cualquier lógica de negocio que calcula Stuff de navegación de un gráfico de objetos causando Hibernate para ejecutar algunas consultas. Mi capacidad para probar este código está cerca de 0% en este momento y eso es un problema. Por lo tanto, mejorar la cobertura de la prueba en otras áreas del proyecto y tratar de funciones puras prefieren más los que tienen acceso a la base de datos, en gran parte porque es más fácil para las pruebas de escritura para esas funciones. Aún así, hay cosas que no pueden, o no deben ser probados.
creo que depende de la parte de la aplicación que se está probando. P.ej. para la lógica de negocio o cualquier componente que implica transformaciones de datos complejas, me gustaría apuntar a 90% (lo más alto posible) de cobertura. He encontrado a menudo pequeños pero peligrosos errores con sólo probar la mayor cantidad de código posible. Yo preferiría encontrar muchas errores durante la prueba de dejar que se producen en el sitio de un cliente un año más tarde. Además, una ventaja de una alta cobertura de código es que evita que los usuarios cambien el código de trabajo con demasiada facilidad, ya que las pruebas tienen que ser adaptados de forma correspondiente.
Por otro lado, creo que hay componentes para los que la cobertura de código es menos adecuado. Por ejemplo, cuando se prueba un GUI es lento para escribir una prueba mucho tiempo que cubre todo el código que se ejecuta cuando se hace clic en un botón con el fin de distribuir el evento a los componentes adecuados. Creo que en este caso es mucho más efectivo utilizar el enfoque tradicional de realizar una prueba manual en el que basta con hacer clic en el botón y observar el comportamiento del programa (no abrir la ventana de diálogo hasta? No la herramienta adecuada ser seleccionado ?).
No tengo que buena opinión sobre el uso de la cobertura de código como una medida para saber cuando el conjunto de pruebas tiene suficiente cobertura.
La razón principal por la cual se debe a que si usted tiene un proceso en el que primero escribir algo de código, a continuación, algunas pruebas, y luego miras la cobertura de código para descubrir dónde ha perdido una prueba, entonces es que proceso que necesita mejorar. Si lo hace cierto TDD, entonces usted tiene una cobertura de código 100% de la caja (la verdad, hay algunas trivialidades que no lo hacen prueba para). Pero si nos fijamos en la cobertura de código para averiguar qué prueba, entonces es probable que escribir las pruebas equivocadas.
Así que la única cosa que se puede concluir de la cobertura de código es que si es demasiado baja, no tiene suficientes pruebas. Pero si es alto, no hay garantía de que tiene todas las pruebas correctas.
