Un equipo informa con orgullo una cobertura de código del 95 % y luego envía un error en una línea que estaba “cubierta”. Esto no es una contradicción. La cobertura responde a una pregunta concreta: ¿las pruebas ejecutaron este código? Si verificaron el resultado es una cuestión completamente diferente.

Usamos Python con cobertura.py 7.17 y pytest 9.2. Cada número e informe a continuación es de nuestra propia ejecución. Las ideas se aplican en cualquier idioma.

¿Qué es la cobertura del código?

La cobertura de código es el porcentaje de su código que se ejecuta mientras se ejecutan sus pruebas automatizadas. Una herramienta registra qué líneas y, opcionalmente, qué ramas se ejecutaron y luego informa lo que se omitió.

Es más útil al revés. La baja cobertura en una zona te indica, con certeza, que las pruebas no la están ejerciendo. Una cobertura alta dice mucho menos.

Tipos de cobertura

Cada nivel es más estricto que el superior. La mayoría de los equipos rastrean la cobertura de líneas y sucursales. La cobertura de condiciones y MC/DC aparecen en los estándares de aviación y automoción, donde el soporte de herramientas es especializado.

El código que medimos

def shipping_fee(total, is_member, express=False):
    if total < 0:
        raise ValueError("total cannot be negative")
    fee = 0 if total >= 1000 else 50
    if is_member:
        fee = max(fee - 25, 0)
    if express:
        fee += 100
    return fee

Nuestro primer archivo de prueba tuvo dos pruebas:

def test_regular_order():
    assert shipping_fee(500, False) == 50

def test_member_express():
    assert shipping_fee(500, True, express=True) == 125

Lo ejecutamos con la medición de rama activada:

coverage run --branch -m pytest test_shipping.py
coverage report -m

leyendo el informe

Name          Stmts   Miss Branch BrPart  Cover   Missing
---------------------------------------------------------
shipping.py       9      1      6      1    87%   3

• Stmts 9, Miss 1: nueve declaraciones ejecutables, una nunca se ejecutó.
• Rama 6, BrParte 1: tres if decisiones dan seis resultados posibles. Una decisión sólo fue en un sentido.
• Falta 3: línea 3, la raise ValueError, nunca se ejecutó. Ninguna prueba pasó un total negativo.

La solución es una prueba de la ruta del error. También agregamos una prueba para un pedido grande:

def test_free_over_1000():
    assert shipping_fee(1000, False) == 0

def test_negative_total():
    with pytest.raises(ValueError):
        shipping_fee(-1, False)

Con ambos archivos, el informe mostró 100% y no faltaron líneas ni ramas parciales. Las rutas de error son los hallazgos clásicos de cobertura de brechas, razón por la cual las pruebas de entradas no válidas, diseñadas con técnicas como partición de equivalencia, combinan tan bien con ellas.

Lo que escondió el informe

Mire el primer informe nuevamente. Dijo que sólo faltaba la línea 3. Pero las dos primeras pruebas utilizaron un total de 500, por lo que la regla de envío gratuito para pedidos de 1000 o más nunca se probó y el informe no la marcó.

La razón es que fee = 0 if total >= 1000 else 50 se encuentra en una línea. cover.py mide las ramas entre líneas, por lo que una expresión condicional dentro de una sola línea cuenta como una declaración ejecutada. Si esa regla tuviera un error, como > en lugar de >=, la primera suite aún habría mostrado un 87% sin ninguna pista. Las pruebas del límite en sí, como se describe en análisis del valor del límite, son las que lo detectan.

Cobertura del 100% sin controles

A continuación, escribimos una prueba deliberadamente deficiente que llama a todos los caminos pero no afirma nada:

def test_runs_everything_but_checks_nothing():
    shipping_fee(500, True, express=True)
    shipping_fee(1000, False)
    shipping_fee(500, False)
    try:
        shipping_fee(-1, False)
    except ValueError:
        pass

shipping.py       9      0      6      0   100%

Alcanzó el 100% de cobertura de líneas y sucursales. La función podría devolver cualquier número y esta prueba aún pasaría. Éste es el límite central de la cobertura: mide la ejecución, no la verificación.

Para medir si las pruebas realmente detectan errores, utilice pruebas de mutación. Una herramienta como mutmut para Python, PIT para Java o Stryker para JavaScript realiza pequeños cambios en su código, como cambiar >= a >, y verifica que una prueba falle. Nuestra prueba de no afirmación permitiría que todas las mutaciones sobrevivieran.

¿Qué objetivo establecer?

No existe un número universalmente correcto. Orientación práctica:

• No persigas el 100%. El último porcentaje a menudo significa probar código trivial o escribir pruebas que solo tocan líneas.
• Muchos equipos apuntan a aproximadamente entre el 70 y el 85 % en general, con expectativas más altas para la lógica empresarial central.
• Observe la tendencia, no el número. La cobertura que cae en cada lanzamiento es una señal de advertencia.
• Requerir cobertura de código nuevo en las solicitudes de extracción en lugar de forzar la publicación del código antiguo de una sola vez.
• Excluye lo que no importa, como el código generado, con reglas claras.

Se aplica la ley de Goodhart: cuando una medida se convierte en un objetivo, deja de ser una buena medida. Los objetivos difíciles fomentan pruebas como nuestro ejemplo de no afirmación.

Herramientas por idioma

Cobertura en CI

Ejecute la cobertura como parte de su canal de CI y publique el informe para que los revisores puedan ver qué líneas nuevas no se han probado. Con cobertura.py, coverage report --fail-under=80 falla la compilación por debajo de un umbral. Mantenga cualquier umbral modesto y combínelo con una regla sobre código nuevo, de modo que un único archivo heredado de gran tamaño no bloquee todos los cambios.

Más allá de la cobertura: mejores preguntas para hacer

• ¿Las pruebas cubren las partes del código riesgosas y que se modifican con frecuencia?
• ¿Se ponen a prueba los límites y los caminos del error, no sólo el camino feliz?
• ¿Fallaría una prueba si esta línea fuera incorrecta?
• ¿Las pruebas son lo suficientemente rápidas y estables como para ejecutarlas en cada cambio?

Estos pertenecen a cualquier estrategia de prueba. La cobertura ayuda a responder solo la primera.

Excluyendo código y leyendo informes HTML

No vale la pena probar algunos códigos directamente, como los asistentes de depuración o un bloque que solo se ejecuta cuando se inicia un script manualmente. cover.py te permite excluir líneas con un comentario:

if __name__ == "__main__":  # pragma: no cover
    main()

También puede establecer exclusiones y las carpetas de origen a medir en la configuración, por ejemplo en pyproject.toml:

[tool.coverage.run]
branch = true
source = ["shop"]

[tool.coverage.report]
show_missing = true
exclude_also = ["if TYPE_CHECKING:"]

Utilice las exclusiones con moderación y revíselas como si fueran código. Cada uno es una decisión que algunas líneas nunca serán revisadas. Excluir un controlador de errores difícil de probar solo para aumentar el número frustra el propósito.

Para el trabajo diario, el informe HTML es más útil que la tabla de terminal. Ejecute coverage html y abra htmlcov/index.html. Cada archivo se muestra con las líneas ejecutadas en verde, las líneas perdidas en rojo y las ramas parciales en amarillo, para que pueda ver de un vistazo cuál if nunca tomó su otra ruta. Muchos editores también pueden mostrar cobertura en el margen, lo que hace que los espacios sean visibles mientras se escribe el código y no después.

Cobertura antes de refactorizar

La cobertura también es una verificación de seguridad antes de refactorizar. Si planea reestructurar un módulo, consulte primero su informe. Las áreas rojas no tienen pruebas para advertirle si el comportamiento cambia, así que agregue pruebas de caracterización que capturen el comportamiento actual antes de comenzar. Utilizada de esta manera, la cobertura deja de ser un objetivo y se convierte en una práctica herramienta de planificación.

El mismo informe ayuda cuando un error pasa a producción. Encuentre la línea donde vivía el error y verifique si alguna prueba lo ejecutó. Si no, has encontrado una brecha que vale la pena cerrar. Si se ejecutó una prueba, el problema es una afirmación débil, que es exactamente la situación que mostró nuestro ejemplo sin afirmación. Ambas respuestas le dicen cómo mejorar la suite.

Conclusión

La cobertura del código es una linterna, no una calificación. Utilice la cobertura de ramas para encontrar código que ninguna prueba toque, especialmente el manejo de errores, y luego escriba pruebas que hagan afirmaciones reales. Si recuerda un resultado de nuestra ejecución, dígalo: se alcanzó una cobertura del 100% mediante una prueba que no comprobó nada.

Preguntas frecuentes

sigue aprendiendo