Niveles de granularidad en la cobertura de código

La granularidad de la cobertura del código es un aspecto importante de las herramientas automatizadas que miden las métricas de cobertura del código para realizar pruebas, pero no todas las herramientas proporcionan el mismo nivel de conocimiento sobre la cobertura del código.

Para determinar el nivel de granularidad admitido, pregúntese "¿Cuál es la unidad más pequeña de código cuyo estado de cobertura puedo determinar sin ambigüedades?" Para muchas herramientas disponibles, la granularidad se limita a líneas individuales. Esta puede ser una limitación mayor de lo que parece a primera vista. El problema clave es que Java, como la mayoría de los lenguajes de programación populares, es un lenguaje de forma libre. Un desarrollador puede escribir una clase Java completa como una línea de código muy larga. Si una herramienta de cobertura que ofrece una granularidad de cobertura basada en líneas informa que esta clase de una sola línea está “cubierta”, ¿qué significa eso exactamente? ¿Significa que se cubrió cada expresión en esa línea, o se informa una cobertura del 100% si se cubrió al menos una expresión en la línea?

Es cierto que el ejemplo de una clase Java que se escribe como una sola línea de código es algo artificial, y tal estilo de programación ya sería motivo de preocupación. Sin embargo, la granularidad basada en líneas puede alcanzar sus límites para algunos modismos bastante comunes. Considere el método del Listado 1.

Public class Listing1 {static int minOrMax (mínimo booleano, int a, int b) {¿mínimo de retorno? Math.min (a, b): Math.max (a, b); }}

Listado 1: Una clase que demuestra los límites de la granularidad de la cobertura basada en líneas.

Es necesaria una única prueba para cubrir parcialmente la línea que contiene la declaración de retorno, pero se necesitan al menos dos casos de prueba para cubrir ambas alternativas de la expresión condicional. Incluso sin utilizar el operador condicional, no es difícil crear situaciones en las que una línea de código se cubra solo parcialmente. Las excepciones durante la ejecución del programa siempre pueden dejar partes de una línea sin cobertura. La granularidad de la cobertura basada en líneas es suficiente para la mayoría de los casos, siempre que la herramienta de cobertura no informe la cobertura completa para las líneas que, en realidad, solo están cubiertas parcialmente. Además, puede ser complicado determinar por qué una línea en particular no está completamente cubierta y qué pruebas deben agregarse para lograr una cobertura completa.

Las herramientas de cobertura que informan la cobertura de expresiones individuales facilitan la identificación de casos de prueba faltantes. La visualización de la granularidad de la cobertura basada en expresiones es un poco más intrusiva. La cobertura basada en líneas se puede mostrar fácilmente en una regla lateral del editor de origen, mientras que la cobertura basada en expresiones requiere marcadores (como colorear o subrayar) en el código fuente mismo.

En casos raros, una expresión aparentemente atómica se traduce en múltiples instrucciones ejecutables, algunas de las cuales pueden no cubrirse bajo ciertas circunstancias. Idealmente, la granularidad de la cobertura llega hasta el nivel de instrucciones individuales. De hecho, muchas herramientas de cobertura recopilan información sobre si se ejecutan o no instrucciones individuales. Sin embargo, la granularidad de los datos recopilados puede reducirse a una cobertura basada en expresiones o en líneas cuando se informa al usuario.

Las razones de la cobertura de bajo código

El problema de aumentar la cobertura de la prueba normalmente se puede reducir a tres escenarios:

• Las pruebas disponibles no utilizan valores de entrada que harán que las expresiones de control para condicionales en el código ejerciten todas las ramas.
• Las expresiones de control en una función probada dependen de los valores devueltos por otras funciones, por lo tanto, del estado del programa / código cuando se ejecuta la prueba.
• Las pruebas disponibles no utilizan la configuración adecuada para el código bajo prueba, por lo que ejecutar una prueba da como resultado una excepción, lo que rompe el flujo de ejecución en el punto de la excepción.

Dependiendo de la estructura del código, las expresiones de control pueden ser triviales (por ejemplo, una instrucción if / else por función) o no (condicionales de bucle anidado con expresiones de control que son retornos de llamadas de función entremezcladas con expresiones de rama). Con base en estos escenarios, en cada caso son apropiadas diferentes técnicas para controlar las condiciones dentro del marco de prueba.

La cobertura no lo es todo

Es común pensar erróneamente que la cobertura es la única métrica de la calidad de conducción. Una vez que los equipos pueden medir la cobertura, no es raro que los gerentes quieran aumentar el número, porque “una cobertura más alta es mejor, ¿verdad? Eventualmente, el número en sí se vuelve más importante que la prueba. Ahí radica el problema: la cobertura debe reflejar el uso real y significativo del código; de lo contrario, es solo ruido. A menos que ciertos tipos y niveles sean requeridos por un estándar de la industria, un producto debe cumplir con la cobertura del código, aunque es importante un enfoque pragmático.

Es importante darse cuenta de que el costo de la cobertura aumenta a medida que aumenta la cobertura. Aumentar la cobertura significa nuevas pruebas que deben mantenerse en el futuro. La necesidad de nuevas pruebas debe justificarse en términos del proyecto general y los objetivos de calidad. La creación de pruebas solo para aumentar la cobertura, introduce costos y deuda técnica.

por Parasoft

Las herramientas de prueba de software automatizadas líderes en la industria de Parasoft respaldan todo el proceso de desarrollo de software, desde que el desarrollador escribe la primera línea de código hasta las pruebas unitarias y funcionales, hasta las pruebas de rendimiento y seguridad, aprovechando los entornos de prueba simulados en el camino.