Cobertura de código con pruebas en Java: de JUnit a JaCoCo en la práctica

Cobertura de código con pruebas en Java: herramientas y métricas en la práctica

¿Alguna vez se ha sentido como el capitán de un barco que está seguro de que su embarcación es insumergible, pero nunca ha revisado el casco en busca de agujeros? Así es más o menos el desarrollo en Java sin analizar la cobertura de código con pruebas. Usted escribe pruebas, pero no sabe qué tan bien protegen realmente su proyecto de errores. En este artículo, analizaremos qué es la cobertura de código con pruebas en Java, qué herramientas de cobertura de código realmente ayudan a no hundirse en regresiones y cómo leer correctamente las métricas para no engañarnos a nosotros mismos.

¿Por qué simplemente "escribir pruebas" no es suficiente?

Muchos desarrolladores piensan: "He escrito 50 pruebas, por lo tanto, el proyecto está protegido". Pero la cantidad de pruebas no equivale a la calidad. Sin métricas, corre el riesgo de:

\n
• Omitir ramas lógicas enteras (por ejemplo, el manejo de excepciones);
\n
• Probar solo los "caminos felices", ignorando los casos límite;
\n
• Perder tiempo en pruebas que no verifican el código nuevo.
\n

Aquí es donde entra en juego code coverage Java: una evaluación objetiva de qué porcentaje del código fuente se ejecuta durante las pruebas. No es una panacea, pero es una brújula poderosa para el equipo.

Métricas principales de cobertura de código en Java

Antes de elegir una herramienta, entendamos qué estamos midiendo exactamente. En el mundo Java, se destacan cuatro métricas clave:

1. Cobertura de líneas (Line Coverage)

La métrica más simple: cuántas líneas de código se ejecutaron al menos una vez. Si una línea no se ejecuta, significa que nadie la ha probado. Ejemplo:

public int divide(int a, int b) {\n    if (b == 0) {\n        throw new IllegalArgumentException("Division by zero"); // Línea 3\n    }\n    return a / b; // Línea 5\n}

Si su prueba llama a divide(10, 2), la línea 3 permanecerá sin cubrir. La cobertura de líneas Java mostrará un 50%.

2. Cobertura de ramas (Branch Coverage)

Esta métrica es más astuta. Verifica si se han recorrido todas las rutas lógicas (if-else, switch, operadores ternarios). Para el mismo método divide:

\n
• Rama 1: b == 0 (true) — lanzamiento de excepción;
\n
• Rama 2: b != 0 (false) — división.
\n

Si solo probó la división, la cobertura de ramas será del 50%. Y si agrega una prueba con b=0, será del 100%.

3. Cobertura de condiciones (Condition Coverage)

Una métrica más profunda que analiza cada subcondición en expresiones complejas. Por ejemplo, en el código if (a > 0 && b < 10), es necesario verificar 4 combinaciones: (true, true), (true, false), (false, true), (false, false).

4. Cobertura de mutaciones (Mutation Coverage)

El estándar de oro. La herramienta (por ejemplo, PIT) introduce pequeños cambios en el código —cambia >= por <, elimina una llamada a método— y observa si al menos una prueba falla. Si la prueba no falla, significa que no es lo suficientemente sensible. Las pruebas de mutación Java son la mejor manera de evaluar la calidad de las pruebas, pero son más lentas.

Principales herramientas de cobertura de código para Java

El mercado ofrece varias soluciones maduras. Veamos las más populares.

JaCoCo — el estándar de la industria

JaCoCo (Java Code Coverage) es una biblioteca de código abierto que se integra en la compilación (Maven, Gradle) y genera informes en HTML, XML o CSV. Admite todas las métricas principales, excepto las mutaciones.

Ejemplo de configuración en Maven (pom.xml):

<plugin>\n    <groupId>org.jacoco</groupId>\n    <artifactId>jacoco-maven-plugin</artifactId>\n    <version>0.8.11</version>\n    <executions>\n        <execution>\n            <goals>\n                <goal>prepare-agent</goal>\n            </goals>\n        </execution>\n        <execution>\n