Significado de las medidas de la cobertura de pruebas unitarias

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.

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)

¿Te ha parecido de utilidad el contenido?

Daniel Rodríguez

Share
Published by
Daniel Rodríguez
Tags: Unit testing

Recent Posts

WOE e IV: La Base Matemática del Credit Scoring

Cuando un banco evalúa una solicitud de crédito necesita responder a una pregunta aparentemente simple:…

5 horas ago

Lanzamiento de la versión 1.0 del laboratorio de Analytics Lane con nuevas herramientas de scoring

En el octavo aniversario de Analytics Lane seguimos ampliando nuestro laboratorio de aplicaciones interactivas y,…

3 días ago

¡Analytics Lane cumple ocho años!

Hoy, 2 de mayo de 2026, Analytics Lane cumple exactamente ocho años. Todo empezó con…

3 días ago

Analytics Lane lanza una Calculadora de Rentabilidad con Flujos Irregulares basada en TIR (XIRR)

La nueva herramienta permite calcular la rentabilidad real de inversiones con múltiples aportaciones, retiradas y…

4 días ago

Analytics Lane lanza un Conversor CSV ↔ JSON para transformar datos en tiempo real

Analytics Lane continúa ampliando su laboratorio de utilidades para desarrolladores y analistas de datos con…

4 días ago

Analytics Lane lanza un nuevo Formateador y Tester de Expresiones Regulares para desarrolladores

Analytics Lane continúa ampliando su laboratorio de herramientas para desarrolladores con el lanzamiento del Formateador…

5 días ago

This website uses cookies.