# Coverage utile: la soglia che ha senso

La coverage conta righe eseguite, non righe verificate. Una soglia utile parte da 80% sulle righe e 70% sui rami, misurata per cartella e non sul totale.

> Pagina: https://ui.eneawork.it/blog/coverage-utile-soglia
> Markdown: https://ui.eneawork.it/blog/coverage-utile-soglia.md

*2026-11-01*

La coverage misura righe eseguite, non righe verificate: un test senza assert alza la percentuale e non prova niente. La soglia utile va messa per cartella, non sul totale del progetto.

Il catalogo EneUI conta 111.985 componenti, 1.556 blocchi e 12.808 icone da 1.472 librerie, misurati da /api/stats il 1 novembre 2026. La cifra viene da una query all'endpoint, non da una stima: conta i record pubblicati, non la qualità dei componenti.

## Cosa misura il numero

Il provider v8 di Vitest, con licenza MIT, legge i contatori del motore JavaScript e riporta quattro valori: righe, rami, funzioni e istruzioni. Nessuno dei quattro guarda gli assert.

## La configurazione che regge

// vitest.config.ts import { defineConfig } from "vitest/config"; export default defineConfig({ test: { coverage: { provider: "v8", reporter: ["text", "json-summary"], thresholds: { lines: 80, branches: 70, functions: 80, statements: 80 }, }, }, });

Le soglie fanno fallire il comando, non solo stampare un numero: è questa la differenza fra una metrica e un contratto. Su un monorepo conviene aggiungere una soglia per cartella con perFile.

## Il comando

npm i -D vitest @vitest/coverage-v8 npx vitest run --coverage

Il pacchetto @vitest/coverage-v8 è MIT e usa i contatori già presenti in Node: nessun servizio esterno, nessun upload, il report resta in CI.

## Record vivi nel catalogo

Tre record con rami veri da coprire: filters, data-table e progress-indicator. Per esplorare per categoria parti da 111.985 componenti.

## La limitazione

La coverage non vede la qualità degli assert: un file al 100% può non verificare nulla. Non misura nemmeno il codice che non esiste ancora, cioè i casi limite che nessuno ha scritto: quelli si trovano leggendo il componente, non il report.

## Dove continuare

Il modello di test è in Testing Library: cinque test; le doppie chiamate che gonfiano i contatori sono in StrictMode; il confronto fra framework è in framework frontend a confronto; il profilo di rendering è in React Profiler.

## FAQ

### Quale soglia di coverage conviene?

80% sulle righe e 70% sui rami per cartella. Sotto resta codice importante scoperto, sopra si inseguono getter e costanti.

### Coverage al 100% vuol dire zero bug?

No. Vuol dire che ogni riga è stata eseguita almeno una volta, non che un assert ne abbia controllato il risultato.

### Misuro le righe o i rami?

I rami, quando devi scegliere. Un if coperto solo sul caso vero resta per metà non testato.

### La coverage rallenta la CI?

Poco. Il provider v8 riusa i contatori del motore, quindi il costo è quasi tutto la scrittura del report.

### Il report va pubblicato?

No, se contiene percorsi interni. Serve al team nella pipeline; online si pubblica al massimo il numero per cartella.