Qu'est-ce que la couverture de test ?

Question

Accepted Answer

**La couverture de test** mesure la quantité de code **exécutée par les tests** — généralement en pourcentage (par exemple 80% de couverture). C'est une métrique utile pour identifier le code non testé, mais il est important de comprendre ses limites : une couverture élevée ne garantit pas de bons tests.

## Ce que la couverture mesure

```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.
```

## Pourquoi la couverture est utile

```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
```

## Les limites (important !)

```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.
```

## Pourquoi c'est important

Comprendre la couverture de test — y compris ses limites — est précieux car c'est une **métrique couramment utilisée** qui est utile quand elle est bien comprise, mais trompeuse quand elle est mal utilisée, donc c'est une connaissance pratique importante.

La couverture mesure **la quantité de code exécutée par les tests** (en pourcentage, via la couverture de ligne, de branche, de fonction ou d'instruction), et la comprendre est utile car elle **identifie le code non testé** (révélant les lacunes où les tests font défaut — un moyen précieux d'identifier ce qui doit être testé), fournit un signal de qualité mesurable que les équipes peuvent suivre, et met en évidence les branches manquées et les cas d'erreur.

De nombreuses équipes utilisent la couverture comme métrique de qualité avec des objectifs.

Cependant, comprendre les **limites est vraiment important** : **une couverture élevée ne signifie pas des bons tests** — la couverture montre que le code a été *exécuté*, non que son comportement a été correctement *vérifié*, donc vous pouvez avoir une couverture élevée (même 100%) avec des tests sans valeur (exécuter du code sans assertions appropriées ne vérifie rien), et une couverture complète peut quand même laisser passer des bugs (combinaisons d'entrées non testées, erreurs logiques).

Le danger de **chasser un nombre de couverture** (écrire des tests de faible valeur juste pour atteindre un objectif) est un vrai anti-pattern.

Comprendre que **la couverture est un guide utile pour trouver les lacunes, pas une garantie de qualité** — et que l'accent devrait être mis sur tester les comportements importants correctement plutôt que sur atteindre un pourcentage — reflète un jugement mature qui évite l'erreur courante de traiter la couverture comme l'objectif plutôt que comme un outil.

Puisque la couverture est une métrique largement utilisée qui est vraiment utile (identifier le code non testé) mais souvent mal comprise et mal utilisée (traitée comme une garantie de qualité ou un objectif à manipuler), et puisque comprendre à la fois sa valeur et ses limites importantes permet de l'utiliser judicieusement, comprendre la couverture de test est une connaissance précieuse et pratiquement pertinente — une métrique utile à bien comprendre, où apprécier ses limites (couverture ≠ qualité) est aussi important que la métrique elle-même, reflétant un bon jugement en matière de test.