¿Informes de cobertura de código separados para pruebas de unidad e integración, o un informe para ambos?

¿Debería haber un informe de cobertura de código separado para las pruebas de unidad e integración, o un informe de cobertura de código para ambos?

La idea detrás de esto es que la cobertura del código nos permite asegurarnos de que nuestro código haya sido cubierto por las pruebas en la medida de lo posible (tanto como una máquina puede ahora de todos modos).

Tener un informe separado es más conveniente para nosotros para saber qué no ha sido cubierto por las pruebas unitarias y qué no ha sido cubierto por las pruebas de integración. Pero de esta manera no podemos ver el porcentaje de cobertura total.

Sobre todo, debe tener y analizar la cobertura combinada (total). Si lo piensa, esta es la forma más natural de priorizar adecuadamente sus riesgos y enfocar su esfuerzo de desarrollo de pruebas.

La cobertura combinada le muestra qué código no está cubierto en absoluto por las pruebas , es decir, es más riesgoso y debe investigarse primero. Los informes de cobertura separados no ayudarán aquí, ya que estos no le permiten saber si el código se prueba de alguna otra manera o no se prueba en absoluto.

El análisis de cobertura por separado también puede ser útil, pero sería mejor hacerlo una vez que haya terminado con el análisis combinado y preferiblemente también involucraría resultados de analizar la cobertura combinada.

El propósito del análisis de cobertura separado difiere del combinado. El análisis de cobertura separado ayuda a mejorar el diseño de su conjunto de pruebas, a diferencia del análisis de cobertura combinada que tiene la intención de decidir qué pruebas se desarrollarán sin importar qué.

"Oh, esta brecha no está cubierta solo porque olvidamos agregar esa prueba simple de unidad (integración) en nuestro conjunto de unidades (integración), agreguémosla": la cobertura y el análisis por separado son más útiles aquí, ya que uno combinado podría ocultar brechas que desea cubrir en particular suite.

Desde la perspectiva anterior, aún es deseable tener también resultados de análisis de cobertura combinados para analizar casos más complicados. Piénselo, con estos resultados, sus decisiones de desarrollo de pruebas podrían ser más eficientes debido a que tiene información sobre las suites de pruebas "asociadas".

"Hay una brecha aquí, pero desarrollar una prueba de unidad (integración) para cubrirlo sería realmente engorroso, ¿cuáles son nuestras opciones? Verifiquemos la cobertura combinada ... oh, ya está cubierta en otra parte, es decir, cubrirla en nuestra suite no es t críticamente importante ".

No mencionas tu herramienta de prueba. Muchos tienen funciones de "combinación" que le permiten agregar los resultados de múltiples ejecuciones o suites. Si desea una métrica de cobertura agregada, explore la función de combinación en su herramienta de cobertura.

Ahora, ¿podemos hablar sobre el elefante en la habitación?

No hay cuchara. Y no hay un "porcentaje de cobertura total". Al menos, no es simple.

El porcentaje de cobertura es una métrica fácilmente comprendida presentada para ayudar a comprender el alcance, la profundidad y el rango de los conjuntos de pruebas. Pero como cualquier punto de referencia simple, es muy fácil convertirse en objetivo fijo en este valor como una especie de talismán mágico de "prueba completa".

Digamos que ha alcanzado la gloria de "100% de cobertura de prueba". ¡Hurra! Pero ¿qué significa eso? El 100% de las líneas de código se prueban, ¿verdad? Entonces, ¿qué pasa con esta línea?

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

"Cubrir" esa línea significa algo, pero no mucho, porque hay una variedad de condiciones que son Trueo Falsecon cierta probabilidad, pero es poco probable que haya probado todas las combinaciones de esas condiciones. Incluso si esa línea está cubierta una docena de veces, si una de las condiciones es relativamente poco común, no ha estado a punto de probar todos los resultados reales que podrían ocurrir en la práctica. Para aclarar eso, un ejemplo más sintético:

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

¿Cuántas veces tendrías que cubrir esa línea para probarla exhaustivamente? ¿Cuántas veces tendrías que cubrirlo para probarlo en combinación con todas las demás variables del programa (con sus propias probabilidades, posiblemente igualmente raras)?

No estoy diciendo que las métricas de cobertura sean inútiles. En realidad son geniales . Se centran en una de las cuestiones clave: ¿con qué frecuencia se prueba mi sistema de software? Ayudan a pasar de "tenemos algunas pruebas" a "hemos probado exhaustivamente".

Pero mientras trabaja en "puntajes combinados", la realidad es que su puntaje será típicamente para "cobertura de declaración" en lugar de "cobertura de condición", "predicado" o "ruta" . Por lo tanto, sea cual sea el número que le den sus puntajes agregados, es poco probable que le brinde una imagen real de la cantidad de estados potenciales de su programa y las combinaciones de estados que se están probando. Mientras trabaja para aumentar su porcentaje de cobertura, considere también medir su cobertura predicada. Le dará una visión más realista, y casi invariablemente, más aleccionadora, de la amplitud de la prueba.