¿Qué es la cobertura de pruebas?

Question

Accepted Answer

**Cobertura de pruebas** mide cuánto del código es **ejecutado por las pruebas** — típicamente como porcentaje (p.ej. 80% de cobertura). Es una métrica útil para encontrar código no probado, pero es importante entender sus limitaciones: una alta cobertura no garantiza buenas pruebas.

## Qué mide la cobertura

```text
TEST COVERAGE = the % of code exercised by the test suite:
  LINE coverage → % of code lines executed by tests
  BRANCH coverage → % of branches (if/else paths) taken
  FUNCTION coverage → % of functions called
  STATEMENT coverage → % of statements executed
→ Coverage tools instrument the code and report what tests do/don't exercise.
```

## Por qué la cobertura es útil

```text
✓ FINDS UNTESTED code — low coverage areas reveal what lacks tests (a gap finder)
✓ A measurable quality signal; track it over time; many teams set a target (e.g. ≥80%)
✓ Highlights branches/paths/error cases that tests miss
```

## Las limitaciones (¡importante!)

```text
⚠️ HIGH COVERAGE ≠ GOOD TESTS:
  → coverage shows code was EXECUTED, NOT that behavior was correctly VERIFIED
  → you can execute code with NO meaningful assertions → 100% coverage, tests verify nothing
  → 100% coverage can still miss bugs (untested input combinations, logic errors)
⚠️ Chasing a coverage NUMBER → writing low-value tests just to hit the target
→ Coverage is a USEFUL guide (find gaps), NOT a guarantee of quality. Use it wisely;
  focus on testing important behavior well, not just hitting a percentage.
```

## Por qué es importante

Entender la cobertura de pruebas — incluyendo sus limitaciones — es valioso porque es una **métrica comúnmente utilizada** que es útil cuando se entiende correctamente pero engañosa cuando se usa incorrectamente, así que es conocimiento práctico importante.

La cobertura mide **cuánto código es ejecutado por las pruebas** (como porcentaje, mediante cobertura de línea, rama, función o sentencia), y entenderla es útil porque **encuentra código no probado** (revelando brechas donde faltan pruebas — una forma valiosa de identificar qué necesita ser probado), proporciona una señal de calidad medible que los equipos pueden seguir, e identifica ramas y casos de error faltantes.

Muchos equipos usan la cobertura como métrica de calidad con objetivos.

Sin embargo, entender las **limitaciones es críticamente importante**: **una alta cobertura no equivale a buenas pruebas** — la cobertura muestra que el código fue *ejecutado*, no que su comportamiento fue correctamente *verificado*, así que puedes tener alta cobertura (incluso 100%) con pruebas sin sentido (ejecutar código sin aserciones adecuadas no verifica nada), y la cobertura completa aún puede perder errores (combinaciones de entrada no probadas, errores de lógica).

El peligro de **perseguir un número de cobertura** (escribir pruebas de bajo valor solo para alcanzar un objetivo) es un anti-patrón real.

Entender que **la cobertura es una guía útil para encontrar brechas, no una garantía de calidad** — y que el enfoque debe estar en probar el comportamiento importante bien en lugar de alcanzar un porcentaje — refleja un juicio maduro que evita el error común de tratar la cobertura como el objetivo en lugar de una herramienta.

Ya que la cobertura es una métrica ampliamente utilizada que es genuinamente útil (encontrar código no probado) pero comúnmente mal entendida y mal usada (tratada como garantía de calidad u objetivo para manipular), y ya que entender tanto su valor como sus limitaciones importantes permite usarla sabiamente, entender la cobertura de pruebas es conocimiento valioso y prácticamente relevante — una métrica útil de entender correctamente, donde apreciar sus limitaciones (cobertura ≠ calidad) es tan importante como la métrica misma, reflejando un juicio de prueba sólido.