En el ámbito de las pruebas de software, la cobertura de código es una métrica empleada frecuentemente para evaluar la eficacia de las pruebas unitarias. En ocasiones, incluso se utiliza para determinar la finalización de tareas de prueba, exigiendo porcentajes elevados como el 80% o 90%. Aunque esto puede incentivar a los desarrolladores a escribir tests, también presenta desafíos y limitaciones. Este artículo explora los distintos tipos de cobertura de código y su verdadero significado.

Para empezar, entendamos qué es la cobertura de código. Se puede definir de manera concisa como:

Cobertura de Código = El grado en que el código fuente es ejecutado por un conjunto de pruebas.

Existen varias formas de medir este "grado de ejecución". A continuación, se describen los tipos más comunes:

1. Cobertura de Sentencias (Statement Coverage)

También conocida como cobertura de líneas, es la forma más básica y extendida. Mide si cada sentencia ejecutable en el código bajo prueba ha sido ejecutada al menos una vez. Es importante recalcar que solo considera sentencias ejecutables, excluyendo declaraciones de encabezado, comentarios o líneas vacías. Es sencilla de entender: se cuenta cuántas líneas de código ejecutable han sido cubiertas. A menudo se le critica por ser el "tipo de cobertura más débil", ya que solo garantiza la ejecución de sentencias, sin tener en cuenta las diversas combinaciones de ramas.

Consideremos un ejemplo simple:

class MathOperations {
    public int performDivision(int dividend, int divisor) {
        return dividend / divisor;
    }
}

Si un desarrollader crea el siguiente caso de prueba:

TestCase: dividend = 10, divisor = 5

Los resultados indicarán que se ha alcanzado el 100% de cobertura de sentencias y que todos los tests han pasado. Sin embargo, lamentablemente, esta cobertura del 100% no detecta un error fundamental: ¿qué ocurre si el divisor es 0? Se lanzaría una excepción de división por cero. Si el objetivo es únicamente alcanzar un porcentaje de cobertura de sentencias, es fácil para un desarrollador diseñar pruebas que cumplan este requisito sin descubrir fallos importantes. Esto plantea varias cuestiones:

1. Confiar únicamente en la cobertura de sentencias para evaluar el trabajo es problemático.
2. El objetivo principal es asegurar la calidad del código, no simplemente alcanzar una métrica.
3. ¿Deberían emplearse métodos de evaluación más sofisticados?

Para buscar mejores criterios, es fundamental conocer otras formas de cobertura. Si la evaluación actual solo considera la cobertura de sentencias, es útil presentar opciones más avanzadas.

2. Cobertura de Decisiones (Decision Coverage)

También denominada cobertura de ramas o cobertura de todas las aristas, mide si cada posible resultado (verdadero o falso) de cada decisión en el programa ha sido probado. Es crucial diferenciarla de la cobertura de condiciones, que se explicará a continuación.

3. Cobertura de Condiciones (Condition Coverage)

Este tipo de cobertura mide si cada subexpresión booleana dentro de una decisión ha sido evaluada tanto como verdadera como falsa. Para ilustrar la diferencia entre cobertura de decisiones y de condiciones, veamos el siguiente fragmento de código:

class InputChecker {
    public boolean checkInputValidity(int paramA, int paramB) {
        if (paramA < 100 || paramB > 0) { // Punto de decisión
            return true; // Rama uno
        } else {
            return false; // Rama dos
        }
    }
}

Para lograr el 100% de cobertura de decisiones, necesitamos que la expresión (paramA < 100 || paramB > 0) sea evaluada como verdadera y como falsa. Podemos diseñar los siguientes casos:

TestCase1: paramA = 50,  paramB = 10    // (True || True) -> True (Cubre Rama uno)
TestCase2: paramA = 150, paramB = -10  // (False || False) -> False (Cubre Rama dos)

Con estos dos tests, obtenemos el 100% de cobertura de decisiones.

Para alcanzar el 100% de cobertura de condiciones, necesitamos que cada subexpresión (paramA < 100 y paramB > 0) se evalúe a verdadero y falso. Los siguientes casos logran esto:

TestCase1: paramA = 50,  paramB = -5   // (True, False) -> True (Cubre Rama uno)
TestCase2: paramA = 150, paramB = 5    // (False, True) -> True (Cubre Rama uno)

Observamos que, aunque hemos logrado el 100% de cobertura de condiciones, solo se ha cubierto la "Rama uno". Esto demuestra que una cobertura de condiciones completa no garantiza una cobertura de decisiones completa, y ambos tipos de cobertura tienen sus limitaciones.

4. Cobertura de Rutas (Path Coverage)

También conocida como cobertura de predicados, mide si cada secuencia única de ramas o "ruta" a través de una función ha sido ejecutada. Esto significa probar todas las posibles combinaciones de bifurcaciones. Como resultado, el número de rutas de prueba puede aumentar exponencialmente con la complejidad del código. Consideremos el siguiente código con dos condiciones independientes:

class ScoreCalculator {
    public int calculateScore(int scoreA, int scoreB) {
        int totalScore = 0;
        if (scoreA >= 70) { // Condición 1
            totalScore += 2;
        }
        if (scoreB < 50) { // Condición 2
            totalScore += 3;
        }
        return totalScore;
    }
}

Apliquemos las coberturas previas a este ejemplo:

a. Cobertura de Sentencias:

TestCase: scoreA = 80, scoreB = 40  // totalScore = 5 (100% de cobertura de sentencias)

b. Cobertura de Decisiones:

TestCase1: scoreA = 80, scoreB = 40  // (C1 True, C2 True) -> totalScore = 5
TestCase2: scoreA = 60, scoreB = 60  // (C1 False, C2 False) -> totalScore = 0
// (100% de cobertura de decisiones)

c. Cobertura de Condiciones:

TestCase1: scoreA = 80, scoreB = 60  // (C1 True, C2 False) -> totalScore = 2
TestCase2: scoreA = 60, scoreB = 40  // (C1 False, C2 True) -> totalScore = 3
// (100% de cobertura de condiciones)

En todos los casos anteriores, logramos un 100% de cobertura. Sin embargo, si analizamos el código, existen cuatro posibles valores de totalScore: 0, 2, 3 y 5. Ninguno de los conjuntos de pruebas anteriores cubre todas estas combinaciones. Esto demuestra que un 100% de cobertura en estos niveles no significa una prueba exhaustiva.

Veamos los casos de prueba para la Cobertura de Rutas:

TestCase1: scoreA = 80, scoreB = 40  // C1 True, C2 True   -> totalScore = 5
TestCase2: scoreA = 80, scoreB = 60  // C1 True, C2 False  -> totalScore = 2
TestCase3: scoreA = 60, scoreB = 40  // C1 False, C2 True  -> totalScore = 3
TestCase4: scoreA = 60, scoreB = 60  // C1 False, C2 False -> totalScore = 0
// (100% de cobertura de rutas)

¡Excelente! La cobertura de rutas ha probado todos los resultados posibles, por lo que a menudo se considera el tipo de cobertura más riguroso.

Existen otros tipos de cobertura, como la Cobertura de Bucles (Loop Coverage), que asegura que los cuerpos de los bucles se ejecuten cero, una y más de una vez. Sin embargo, no profundizaremos en ellos en este artículo.

Reflexiones sobre la Cobetrura

Después de explorar los distintos tipos, es importante reflexionar sobre el verdadero valor de los datos de cobertura. Aquí algunas conclusiones clave:

• La cobertura de código solo indica qué partes del código han sido ejecutadas, no garantiza la calidad o corrección de esa ejecución (como vimos con el error de división por cero).
• No se debe confiar ciegamente en los porcentajes de cobertura.
• Evite utilizar únicamente la cobertura de sentencias para evaluar el rendimiento de los desarrolladores o QA.
• Existe una jerarquía de efectividad: Cobertura de Rutas > Cobertura de Decisiones > Cobertura de Sentencias.
• Los ingenieros de pruebas deben priorizar el diseño de casos de prueba robustos e inteligentes, incluso si no incrementan directamente el porcentaje de cobertura existente.

Principios para Pruebas Unitarias Efectivas

Para maximizar el valor de las pruebas unitarias, considere las siguientes buenas prácticas:

1. Organice el código de prueba en directorios dedicados (ej. src/test/java).
2. Utilice convenciones de nomenclatura claras para clases (ej. *Test.java) y métodos de prueba (ej. test*).
3. Asegure que los métodos públicos o protegidos de la clase bajo prueba estén cubiertos.
4. Aísle las pruebas usando mocks o stubs para llamadas a interfaces externas, bases de datos o servicios.
5. Mantenga la granularidad: una clase de prueba debe corresponder a una clase funcional, y un método de prueba a una funcionalidad específica o método principal de la clase.
6. Cada caso de prueba debe enfocarse en una funcionalidad o escenario particular.
7. Evite deshabilitar pruebas con anotaciones como @Disabled (o @Ignored) o comentándolas; si una prueba falla constantemente, arréglela o elimínela.
8. Las pruebas deben ser independientes del entorno de ejecución.
9. Utilice entradas de prueba concretas y evite valores no determinísticos (ej. System.currentTimeMillis()).
10. Las pruebas deben tener un resultado predecible y reproducible.
11. Asegúrese de que los tests sean idempotentes, es decir, que ejecutar el mismo test varias veces produzca siempre el mismo resultado y no altere el estado del sistema de forma irreversible.