Cobertura de código

La cobertura de código mide qué parte del código se ejecutó durante una ejecución de pruebas. Una herramienta instrumenta el código (JaCoCo para Java, Istanbul/nyc o la cobertura de V8 para JavaScript, coverage.py para Python), ejecuta las pruebas e informa de qué líneas y ramas se alcanzaron. Es una métrica de caja blanca y se recoge sobre todo en pruebas unitarias y de integración.

Tipos de cobertura

Considera:

int shippingCost(double total, boolean isMember) {
    if (total >= 100 || isMember) {
        return 0;
    }
    return 5;
}

• Cobertura de sentencias (líneas): ¿se ejecutaron las dos sentencias return? Dos pruebas, (150, false) y (20, false), dan el 100 %.
• Cobertura de ramas (decisiones): ¿el if fue tanto verdadero como falso? Las mismas dos pruebas también dan el 100 %.
• Cobertura de condiciones: ¿cada subcondición booleana se evaluó como verdadera y como falsa? Las pruebas anteriores nunca hicieron verdadero isMember, así que no está completa. Añadir (20, true) lo soluciona.
• Cobertura de funciones: ¿se llamó a cada función al menos una vez?

En general, la cobertura de ramas es un objetivo más útil que la de líneas, porque una sola línea puede esconder varios caminos.

Lo que la cobertura no te dice

La cobertura demuestra que el código se ejecutó, no que se verificara. Esta prueba da un 100 % de cobertura de líneas y de ramas del método anterior y no verifica nada:

@Test
void runsShippingCost() {
    shippingCost(150, false);
    shippingCost(20, false);
}

La cobertura tampoco puede revelar código que falta. Si el requisito dice que los socios de cierta región pagan el envío y nadie lo implementó, no hay líneas que puedan quedar sin cubrir. Las pruebas de mutación son la forma habitual de medir si las pruebas realmente detectan fallos.

Cómo usarla bien

• Mira las líneas no cubiertas, no solo el número. Un manejador de errores sin probar en el flujo de pago importa más que un toString() sin probar.
• Pon el umbral sobre la cobertura del código modificado, por ejemplo “el código nuevo debe tener al menos un 80 % de cobertura de ramas”, en lugar de un porcentaje global que empuja a la gente a probar getters triviales.
• Nunca trates el 100 % como objetivo. Cuando una métrica se convierte en meta, aparecen pruebas sin assertions.