La cobertura ayuda a saber lo que no estamos probando. Nos ayuda poco a saber si estamos probando bien lo que estamos probando.
Hay discusión sobre la utilidad de la mediciones de cobertura. Por ejemplo ver el resumen de una discusión sobre el tema, de donde tomo la idea que lo único seguro sobre la cobertura es que nos indica que partes no hemos probado.
Por mi parte, hice un rant sobre el uso del % de cobertura como métrica, sobre todo por parte de personas que aprendieron el concepto sólo como un subproducto de TDD.
Pero si entendemos las características de la cobertura, puede ser una ayuda importante para la actividad de prueba (sea quien sea que haga esa actividad).
Hay muchos tipos de cobertura. Por ejemplo, podemos comprobar si estamos probando que se cumplan los objetivos de negocio, o los requerimientos, si hemos probado todos los riesgos identificados, todo el código o las entradas y salidas del programa.
La cobertura de código es la más común de las métricas de cobertura, quizás porque es la más fácil de medir. Incluso dentro de las cobertura de código, hay muchas posibles coberturas: de clase, de método, de linea, de instrucción, condicionales, de camino, etc.
En toda métrica de cobertura, se define el universo de los puntos posibles, y luego se mide cuantos de estos puntos están siendo cubiertos por algún caso de prueba.
Por ejemplo, en una cobertura de líneas de código, cada línea es un punto. Si esa linea es ejecutada al correr alguna prueba, se dice que ese punto está cubierto.
Se puede tomar el porcentaje de cobertura como la cantidad de puntos cubiertos sobre la cantidad total de puntos.
Pero como dijimos anteriormente, es más valioso conocer los puntos no cubiertos.
La herramienta
La herramienta que estoy por comentar, jXmlCoverage, mide cobertura basada en los XML utilizados por el Sistema bajo Prueba (en inglés, SUT).
En muchos SUT se utiliza XML, como entrada, salida o configuración. Por ejemplos, los Web Service. En estos SUT, se dispone, o se puede crear, un XSD que corresponda al contrato que daebe cumplir los XML correspondientes.
Nos interesa el grado en que nuestras pruebas ejercitan las diferentes posibilidades de valores en los XML, y sobre todo, saber que valores no estamos probando.
Para esto, debemos definir el universo que queremos medir. Lo que hacemos es, para cada elemento definido en el XSD, decidir las particiones de equivalencia que son interesantes tomar. Por ejemplo, para un entero, podrían ser los enteros positivos, el cero, los negativos y un valor fuera de rango. A esto lo llamamos subdominio. Cada subdominio es un punto sobre el que se medirá cobertura.
Pasada la etapa de definición y configuración del universo de prueba, medimos la cobertura.
Para medir la cobertura se toma el conjunto de los XML usados y se evalúan contra los subdominios, contando cuantas veces un subdominio es utilizado (cubierto) por los casos de prueba.
Como resultado, podemos obtener los subdominios que no fueron cubiertos.
Como en todas las mediciones de cobertura, se debe evitar caer en la tentación de considerar un sub-dominio cubierto como un sub-dominio bien probado.
