En una entrada reciente se ha explicado cómo medir la cobertura de las pruebas unitarias en un proyecto JavaScript. Para lo que se utilizaron los informes creados con Istanbul. Los informes contenían cuatro valores que generalmente son diferentes: líneas, funciones, sentencias y ramas. Así es normal preguntarse qué mide concretamente cada uno de estos valores, ya medidas diferentes para las mismas pruebas. En esta entrada se explicarán estas cuatro medidas de cobertura de pruebas unitarias.
Tabla de contenidos
Definición de las medidas de cobertura de pruebas unitarias
En primer lugar, es necesario definir lo qué mide cada una de las medias de cobertura que se obtienen con Istanbul.
Funciones (“functions”)
Esta es la medida más simple de las cuatro. Simplemente mide el porcentaje de funciones que son testeadas al ejecutarse las pruebas unitarias. En esta métrica se contará como evaluada la función solamente si se ejecuta, sin tener en cuenta su tamaño o complejidad.
Líneas (“lines”)
Las líneas es otra métrica fácil de interpretar. Esta medida cuenta el porcentaje de líneas del total que son ejecutadas en las pruebas unitarias. Para lo que no se tienen en cuenta ni comentarios ni líneas en blanco. A diferencia de la medida anterior, en esta se tiene en cuenta el tamaño del código, por lo que es un valor más fiable.
Sentencias (“statements”)
Este valor de cobertura indica el porcentaje de sentencias que son testeadas al ejecutarse las pruebas unitarias. En la mayoría de las ocasiones una sentencia es una línea, pero no siempre es así ya que se pueden dividir sentencias en varias líneas y escribir más de una sentencia en una línea.
Ramas (“branches”)
Finalmente la última medida del grado de cobertura se basa en el porcentaje de ramas que se ejecutan del código. Una rama es cualquier bifurcación que se puede producir durante la ejecución. Por lo que el objetivo de esta métrica es garantizar que se cubre todas las rutas posibles.
Ejemplos de las métricas de cobertura
La mejor forma de comprender lo que mide cada uno de los valores definidos anteriormente es mediante un ejemplo. Para lo que se puede utilizar el siguiente código, que no tiene ninguna utilidad en particular.
const index = exports;
index.test = function (a, b) {
if (a > 1 && b > 1) {
var c = a + b; return c;
} else if (a > 0) {
return a;
} else {
return -a;
}
};Ahora se pueden escribir dos pruebas.
var expect = require('chai').expect;
var index = require('../index.js');
suite('Basic suite', function () {
test('Basic test', function (done) {
expect(index.test(2, 0)).to.be.equal(2);
expect(index.test(0, 0)).to.be.equal(0);
done();
});
});Obteniéndose los siguientes resultados.
----------|----------|----------|----------|----------|-------------------| File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s | ----------|----------|----------|----------|----------|-------------------| All files | 75 | 83.33 | 100 | 85.71 | | index.js | 75 | 83.33 | 100 | 85.71 | 5 | ----------|----------|----------|----------|----------|-------------------|
En donde se puede ver que cada una de las métricas mide un valor diferente. El grado de cobertura en base a las funciones es del 100%, se ha ejecutado la única función. En cuanto al grado de cobertura en base a las líneas es de 85,71%, se han ejecutado 6 de 7 líneas. Tal como se indica en el informe no se ha ejecutado la línea 5. El nivel de cobertura en base a sentencias es menor, solamente del 75%, se han ejecutado 6 de las 8 sentencias. La diferencia aparece porque la línea 5 contiene dos sentencias, una asignación y el retorno del valor.
Finalmente, el grado de cobertura de las ramas es del 83,33%, al evaluarse 5 de las seis. En este caso, al igual que en la anteriores, el problema aparece por escribir una prueba que ejecute la línea 5.
¿Qué medida de la cobertura de pruebas unitarias utilizar?
El objetivo debería ser tener una cobertura de las pruebas unitarias del 100% por los cuatro valores. Por lo que al alcanzar este hito es importante diferenciar los valores. Pero en el caso de no llegar al 100%, el más problemático es cobertura de funciones. Ya que indicaría que ni siquiera se ha escrito una prueba para algún método. Los valores de cobertura de líneas y sentencias son bastante similares. Por otro lado, la cobertura por ramas es un buen indicador del número de pruebas que quedan por escribir.
Conclusiones
En esta entrada se ha visto el significado de los diferentes medidas de la cobertura de pruebas unitarias que ofrece Istanbul. Los cuales son importante conocer para saber que indica un informe de estos. A pesar de utilizar el ejemplo de Istanbul, lo aquí aprendido se puede utilizar con otros programas.
¿Qué valores de la cobertura de las pruebas unitarias os parece más importante? ¿En cual os fijáis más? Podéis dejar las respuestas en los comentarios de la entrada.
Imágenes: Pixabay (Peggy Choucair)
Deja una respuesta