Cos'è la copertura dei test?

Question

Accepted Answer

**La copertura dei test** misura quanto del codice è **eseguito dai test** — tipicamente come percentuale (ad es. 80% di copertura). È una metrica utile per trovare il codice non testato, ma è importante comprenderne i limiti: un'alta copertura non garantisce test di qualità.

## Cosa misura la copertura

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

## Perché la copertura è 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
```

## I limiti (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.
```

## Perché è importante

Comprendere la copertura dei test — inclusi i suoi limiti — è prezioso perché è una **metrica comunemente utilizzata** che è utile se compresa correttamente ma fuorviante se usata male, quindi è una conoscenza pratica importante.

La copertura misura **quanto codice è eseguito dai test** (come percentuale, tramite copertura di linea, ramo, funzione o istruzione), ed è utile comprenderla perché **trova il codice non testato** (rivela lacune dove i test sono insufficienti — un modo prezioso per identificare cosa ha bisogno di test), fornisce un segnale di qualità misurabile che i team possono tracciare, e evidenzia rami mancanti e casi di errore.

Molti team usano la copertura come metrica di qualità con obiettivi.

Tuttavia, comprendere i **limiti è criticamente importante**: **un'alta copertura non equivale a buoni test** — la copertura mostra che il codice è stato *eseguito*, non che il suo comportamento è stato correttamente *verificato*, quindi puoi avere un'alta copertura (anche del 100%) con test insignificanti (eseguire il codice senza asserzioni adeguate non verifica nulla), e una copertura completa può comunque perdere bug (combinazioni di input non testate, errori logici).

Il pericolo di **inseguire un numero di copertura** (scrivere test di basso valore solo per raggiungere un obiettivo) è un vero anti-pattern.

Comprendere che **la copertura è una guida utile per trovare lacune, non una garanzia di qualità** — e che l'attenzione dovrebbe essere sul testare bene il comportamento importante piuttosto che raggiungere una percentuale — riflette un giudizio maturo che evita l'errore comune di trattare la copertura come l'obiettivo piuttosto che uno strumento.

Poiché la copertura è una metrica ampiamente utilizzata che è genuinamente utile (trovare il codice non testato) ma comunemente fraintesa e usata male (trattata come garanzia di qualità o come obiettivo da ingannare), e poiché comprenderne sia il valore che i suoi importanti limiti permette di usarla saggiamente, comprendere la copertura dei test è una conoscenza preziosa e praticamente rilevante — una metrica utile da comprendere correttamente, dove apprezzare i suoi limiti (copertura ≠ qualità) è importante quanto la metrica stessa, riflettendo un solido giudizio nei test.