Guida utente

1. Introduzione

Fucini Coverage Studio trasforma i file di traccia della coverage che la vostra build già produce in coverage di prima classe nell'editor — in VS Code e in Visual Studio. Legge venticinque formati, li normalizza in un unico modello canonico Fucini, unisce più esecuzioni in modo deterministico e mostra il risultato nell'editor stesso — margini, CodeLens, hover e una vista Covered Files — così non c'è un visualizzatore separato per cui lasciare l'editor. Le due edizioni condividono un lettore: lo stesso report dà gli stessi numeri, alla cifra, in entrambe. Questa guida è scritta da VS Code; dove Visual Studio differisce, un riquadro In Visual Studio dice come.

È costruito pensando ai flussi di lavoro di sicurezza funzionale: coverage MC/DC, coverage di regioni e istanziazioni C++, un punteggio composito ponderato per la sicurezza e un verdetto configurabile COMPLIANT / NON-COMPLIANT allineato al pensiero IEC 61508, ISO 26262 e DO-178C.

Screenshot pending — add assets/img/marketplace-demo.gif (see SCREENSHOTS.md).

2. Installazione e requisiti

• VS Code ≥ 1.88 — la versione minima supportata da questa estensione — oppure Visual Studio 2022 o 2026, Community, Professional o Enterprise (vedi il riquadro qui sotto).
• Un file di traccia della coverage che il vostro progetto già produce (vedi §4).

Installa dal Marketplace, oppure da un file .vsix tramite Extensions → ⋯ → Install from VSIX…. L'estensione si attiva all'avvio e aggiunge un'icona Coverage alla activity bar.

3. Avvio rapido

1. Genera un file di traccia di coverage con il tuo normale flusso di test.
2. Command Palette (Ctrl+Shift+P) → Fucini Coverage: Load Coverage. Con watch.enabled attivo (predefinito), un file corrispondente si carica automaticamente.
3. Apri un file sorgente coperto: la barra di stato mostra la sua percentuale, la vista Coverage si popola, passando il mouse su una riga si vede il suo conteggio dei colpi, e l'esecuzione compare nel pannello nativo Test Coverage. Barre sulle righe non coperte, una mappa di calore dei conteggi e conteggi ×N in linea sono a un'impostazione di distanza (editorGutter.mode, hitCounts.inline).

Screenshot pending — add assets/img/gutters.png (see SCREENSHOTS.md).

4. Produzione di file di traccia

Uno qualsiasi dei seguenti viene rilevato automaticamente al caricamento:

C / C++ — LLVM (llvm-cov)

clang --coverage -fprofile-instr-generate -fcoverage-mapping test.c -o test
LLVM_PROFILE_FILE=test.profraw ./test
llvm-profdata merge -sparse test.profraw -o test.profdata
llvm-cov export ./test -instr-profile=test.profdata --format=json > coverage.json

llvm-cov JSON è l'input più ricco — porta con sé regioni, MC/DC e istanziazioni di template C++ oltre a righe, rami e funzioni.

C / C++ — GCC (gcov → lcov)

gcc --coverage calc.c calc_test.c -o test && ./test
lcov --capture --directory . --output-file lcov.info
# or gcovr --cobertura coverage.xml
# or skip the conversion entirely: gcovr --json coverage.json

JavaScript / TypeScript — Istanbul / nyc

nyc --reporter=json mocha        # emits coverage/coverage-final.json

Java — JaCoCo

mvn test        # emits target/site/jacoco/jacoco.xml

Ruby — SimpleCov

# .resultset.json (built-in) or coverage.json via the simplecov-json gem

Go

go test ./... -coverprofile=coverage.out    # read directly, no conversion

Python — coverage.py

coverage run --branch -m pytest && coverage json    # emits coverage.json

PHP — PHPUnit (Clover)

XDEBUG_MODE=coverage phpunit --coverage-clover clover.xml

.NET / C# — Coverlet (OpenCover)

dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover

Un progetto C++ nativo, misurato da Visual Studio

Screenshot pending — add assets/img/vs-native-run.gif (see SCREENSHOTS.md).

5. Caricamento e rilevamento

Per impostazione predefinita l'estensione esegue la scansione dalla radice dello spazio di lavoro. Precisa questo con due impostazioni:

{
  "fuciniCoverage.coverageFile.defaultLocation": "${workspaceFolder}/build",
  "fuciniCoverage.coverageFile.paths": [
    "coverage.json",
    "reports/*.info",
    "${env:CI_ARTIFACTS}/lcov.info",
    "https://ci.example.com/artifacts/latest/coverage.xml"
  ]
}

• Ogni voce di paths è relativa a defaultLocation (o alla radice dello spazio di lavoro se non impostata).
• Una voce contenente * viene cercata ricorsivamente; un nome file semplice corrisponde solo direttamente nella cartella base.
• Quando paths è vuoto, l'estensione cerca coverage.json, poi lcov.info, caricando quello trovato per primo.
• Pick Coverage File usa i file selezionati al posto di questi percorsi — ogni selezione si aggiunge all’insieme e tutti vengono uniti — finché non li si scarica o non si modificano queste impostazioni.
• Variabili — ogni impostazione di percorso espande ${workspaceFolder}, ${workspaceFolderBasename}, ${userHome}, ${env:NAME}, ${command:id} e ${config:section.key}. Una variabile che l'estensione non conosce viene lasciata com'è scritta, così un errore di battitura compare nel log di rilevamento come il percorso cercato anziché sparire. ${command:id} esegue prima quel comando — solo in un’area di lavoro attendibile e per al massimo cinque secondi — così ${command:cmake.buildDirectory} segue il kit CMake selezionato.
• Voci URL — una voce http(s):// viene scaricata nell'archivio dell'estensione a ogni caricamento e caricata da lì; la vista Coverage nomina l'URL. Ogni scaricamento è condizionale (ETag / Last-Modified), così un artefatto invariato non trasferisce nulla, e quando uno scaricamento fallisce viene caricata l'ultima copia scaricata, con il motivo nell'output. remote.headers aggiunge intestazioni Name: value con le variabili espanse, remote.refreshMinutes riscarica a intervalli, e un frammento #lcov.info indica il formato quando l'URL stesso non termina con un nome di file.
• Glob di esclusione — fuciniCoverage.ignore esclude file interi (vendorizzati, generati, di terze parti) dall'esecuzione mentre si carica, così ogni vista, gate ed esportazione conta senza di essi; il risultato del caricamento dice quanti sono stati lasciati fuori e l'output li nomina. I pattern corrispondono al percorso relativo allo spazio di lavoro e a quello assoluto, e un pattern senza / corrisponde a un nome di cartella o di file a qualsiasi profondità, come .gitignore.
• Spazi di lavoro multi-root — ogni cartella viene rilevata per conto proprio: defaultLocation, paths, pathRemap, ignore, watch.* e remote.* vengono letti per cartella, così vale il .vscode/settings.json della cartella stessa o la sua voce nel .code-workspace, e ${workspaceFolder} in una voce indica la cartella della voce stessa. I tracefile di ogni cartella si uniscono in un'unica esecuzione, la vista Coverage raggruppa i file per cartella, e una cartella aggiunta allo spazio di lavoro o rimossa da esso ricarica la copertura da sola.
• Ricaricamento dopo un'attività — watch.reloadAfterTasks nomina attività (una label di tasks.json, o source: name come le mostra l'elenco Run Task) la cui fine ricarica la copertura, che watch.enabled sia attivo o no — per le build che l'osservatore non può seguire. Anche una voce assoluta di paths fuori dallo spazio di lavoro viene sondata, così un file che compare lì viene caricato.
• Avanzamento annullabile — un caricamento di dieci o più tracefile, o di 8 MB o più, gira sotto una notifica di avanzamento con un pulsante Annulla che nomina il file in lettura e la fase; uno più piccolo fa solo girare la barra di stato. Annullare lascia caricata l'esecuzione precedente e lo dice.

Dalla 1.2026.6 anche una voce assoluta può contenere una wildcard: ${workspaceFolder}/build/coverage-merged/*.lcov.info carica ogni file del genere in quella cartella, e ** sta per qualsiasi profondità. Le cartelle prima della prima wildcard sono dove cerca, e vengono osservate, così un report che una build scrive lì si carica da solo. L’edizione per Visual Studio legge una voce così allo stesso modo, e dalla 1.2026.5 anche lì una wildcard relativa viene cercata a qualsiasi profondità, come è sempre stato qui.

Se paths non è configurato, viene caricato il primo dei nomi di report più diffusi trovato sotto la cartella di base. Prima i quattro che l'estensione ha sempre cercato — coverage.json, lcov.info, coverage.out, clover.xml — poi, dalla versione 0.2026.83, jacoco.xml, coverage.xml, cobertura.xml, coverage.cobertura.xml, coverage.opencover.xml e coverage-final.json, e infine i percorsi in cui scrivono le configurazioni predefinite: coverage/ (nyc, Jest, vitest, PHPUnit, SimpleCov), target/site/jacoco/jacoco.xml (Maven), build/reports/jacoco/test/jacocoTestReport.xml (Gradle) e TestResults/*/coverage.cobertura.xml (dotnet test). Così un progetto Java o .NET mostra la propria copertura alla prima apertura, come ha sempre fatto un progetto lcov.

Dalla 1.2026.3 una soluzione .NET ha bisogno di ancora meno: la cartella TestResults/<run>/ di ogni progetto di test è tra i percorsi noti, non solo quella della cartella dello spazio di lavoro, e il <user>_<machine>_<date>.cobertura.xml del collector di Microsoft viene trovato accanto al coverage.cobertura.xml di Coverlet — così una soluzione i cui test sono stati eseguiti nel Test Explorer di Visual Studio mostra la sua coverage alla prima apertura, ogni cartella di esecuzione viene caricata, e l'unione conserva per ogni file quanto dice l'esecuzione più recente. E fuciniCoverage.ignore.generated, attivo per impostazione predefinita, lascia i file del designer e quelli generati — *.Designer.cs, *.g.cs, *.generated.cs, *.razor.g.cs, AssemblyInfo, gli using globali, Migrations/ e obj/ — fuori da ogni totale, pagina ed esportazione prima che venga applicato ignore, così una tabella generata che nessuno testa non costa alla soluzione il suo gate.

Un artefatto CI dietro un token, ricontrollato ogni quarto d'ora — il token resta nell'ambiente, mai in settings.json:

{
  "fuciniCoverage.coverageFile.paths": [
    "https://ci.example.com/api/builds/latest/artifacts/coverage#lcov.info"
  ],
  "fuciniCoverage.remote.headers": ["Authorization: Bearer ${env:CI_TOKEN}"],
  "fuciniCoverage.remote.refreshMinutes": 15
}

Screenshot pending — add assets/img/remote-tracefile.png (see SCREENSHOTS.md).

Un ricaricamento è silenzioso di proposito: una finestra di dialogo dopo ogni build è una domanda con una sola risposta. Non è silenziosa l’icona Coverage: finché la vista non è davanti a te, porta il numero di tracefile riletti e il suo suggerimento li nomina. Apri la vista e il conteggio sparisce.

Screenshot pending — add assets/img/coverage-badge.gif (see SCREENSHOTS.md).

File che non devono contare mai, qualunque cosa ne dica il tracefile:

{
  "fuciniCoverage.ignore": ["vendor/**", "**/*.generated.ts", "build/**"]
}

Un ricaricamento alla fine dell'attività di test, per una build che l'osservatore dei file non può seguire — un'esecuzione che sostituisce un albero di output con link simbolici, un report su una condivisione di rete, un passo di copertura che post-elabora il proprio file:

{
  "fuciniCoverage.watch.reloadAfterTasks": ["npm: test", "coverage-report"]
}

6. Unione delle esecuzioni

Ogni voce paths esistente viene caricata e fusa in un’unica esecuzione. La fusione è deterministica — il risultato non dipende dall’ordine di caricamento — e un file misurato da più di un tracefile prende i suoi numeri da quello con la mtime più recente su disco: la riesecuzione di un modulo sostituisce ciò che un’esecuzione più ampia e più vecchia diceva di esso, invece di aggiungersi. La vista Copertura mostra cosa ha fatto: ogni riga di file nomina il tracefile da cui vengono i suoi numeri, il badge ha un contorno dove quei numeri hanno prevalso su un report più vecchio, ogni riga di tracefile sopra l’albero conta quanti dei suoi file sono stati sostituiti o ne hanno sostituiti altri, e un clic su una riga di tracefile evidenzia i suoi file nell’albero finché non viene cliccata di nuovo (coverageView.mergedMarks disattiva contorno ed evidenziazione).

Screenshot pending — add assets/img/four-reports-one-file.svg (see SCREENSHOTS.md).

Un'esecuzione unita può contenere più delle sei metriche classiche, ciascuna proveniente dal report che la misura: chiamate di funzione, codice oggetto e un punteggio di mutazione accanto a righe, funzioni, regioni, rami, MC/DC e istanziazioni. La vista Coverage mostra una colonna per ogni metrica contenuta nell'esecuzione — e nessuna per quelle che non contiene — ordinate per il peso che ogni metrica ha nel punteggio, dalla più pesante, a qualsiasi larghezza: ciò che non entra scorre lateralmente invece di sparire. Trascinando la vista nel pannello inferiore diventa una tabella. Le schede della barra di stato, il report HTML e le esportazioni CSV e Markdown seguono la stessa regola: ciò che un report contiene viene mostrato, ciò che non contiene viene omesso anziché essere stampato come uno zero.

Screenshot pending — add assets/img/coverage-view-editor.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/coverage-view-columns.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/workspace-overview.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-workspace-overview.gif (see SCREENSHOTS.md).

Da quale report viene un file

Quando più report caricati misurano lo stesso file, il più recente se lo aggiudica per intero — giusto quando la nuova esecuzione di un modulo sostituisce quanto diceva un'esecuzione più vecchia e più ampia. È sbagliato quando i report misurano lo stesso codice di proposito: allora l'editor salta dall'uno all'altro a ogni build, e ciascuno racconta solo una parte della storia. coverageFile.sources dice cosa fare invece, file per file. Tre situazioni lo richiedono:

• Un report è il migliore. Il coverage.json di llvm-cov contiene MC/DC, un gcov.info di GCC della stessa build solo righe e rami: scegli coverage.json, e tieni l'altro per i pochi file che solo GCC compila.
• Più suite di test di una stessa build. Test unitari, test di integrazione e hardware-in-the-loop scrivono ciascuno un report; ognuno da solo tralascia righe che gli altri hanno eseguito. Combina, union: una riga è coperta dove l'ha eseguita un qualsiasi report, e i conteggi si sommano.
• Un solo codice, due compilatori. Gli stessi sorgenti compilati da clang e da GCC seguono percorsi diversi nel codice specifico di ciascuna toolchain — un intrinsic qui, un fallback portabile là — e ogni report dice che l'altra metà non è mai stata eseguita. Combina, agree: una riga è coperta solo dove l'ha eseguita ogni report che la misura, e le righe su cui non concordano sono segnate in verde acqua. È la domanda che pone un controllo incrociato tra compilatori: cosa ha davvero esercitato ogni build che rilascio?

Raramente scrivi le regole a mano. Fai clic con il tasto destro su un file nella vista Copertura e scegli Choose Coverage Source... (oppure esegui Choose Coverage Source for This File... sul file aperto): l'elenco mostra ogni report che misura il file, ciascuno con le proprie righe, i propri rami e MC/DC, poi Combine them — agree e Combine them — union; scegline uno e indica se vale per il file, la sua cartella o un pattern. Clear Coverage Source for This File... toglie di nuovo la regola. Nelle impostazioni ogni regola è un glob sui file, un glob sul report (un pattern senza / corrisponde al nome file del report, {a,b} ne indica più d'uno) e, per combinare, "combine": "agree" o "union". Decide la prima regola i cui file corrispondono e il cui report misura il file; un file misurato da un solo report non gli viene mai tolto. Rami, MC/DC e regioni di un file combinato vengono dal report che ne è più ricco. coverageFile.mergeStrategy: "order" decide i file per cui nessuna regola si esprime in base all'ordine di coverageFile.paths anziché agli orari.

{
  "fuciniCoverage.coverageFile.paths": ["clang.json", "gcc/bits.gcov.json.gz"],
  "fuciniCoverage.coverageFile.sources": [
    { "files": "src/**", "report": "{clang.json,bits.gcov.json.gz}", "combine": "agree" }
  ]
}

Cosa vedi: la riga del file nella vista Copertura indica il report da cui vengono i suoi numeri oppure, se combinato, ogni report e la modalità, con ≠ n per le righe contese. Il gutter e l'Annotated Source segnano quelle righe in verde acqua e dicono quale report le ha eseguite e quante volte. La scheda che compare al passaggio del mouse sulla barra di stato indica l'origine del file aperto e, per l'intera esecuzione, le regole in vigore e come sono stati decisi gli altri file. Il samples/c-cross-check della demo è il caso dei due compilatori, pronto da aprire. Anche Visual Studio fa tutto questo: Choose Coverage Source... su una riga della vista Copertura, e Choose e Clear Coverage Source for This File... in Tools > Coverage Studio.

Scegliere e combinare le origini fa parte dei piani a pagamento. Su Community il report più recente vince ogni file, come senza alcuna regola, e una regola nelle impostazioni viene segnalata come inutilizzata anziché ignorata in silenzio.

7. Rimappatura dei percorsi

La CI spesso registra percorsi assoluti della macchina di build che non esistono sulla tua workstation. Riscrivili con regole ordinate:

{
  "fuciniCoverage.pathRemap": [
    { "from": "/builds/ci/project", "to": "${workspaceFolder}" },
    { "from": "\\\\", "to": "/" }
  ]
}

Le regole si applicano in ordine; la prima corrispondenza vince per prefisso. Usa questo per uniformare le differenze dei separatori Windows/Unix o mappare un percorso container sul tuo checkout.

Raramente devi scrivere la regola da solo. Il più comune «ha caricato ma non si accende nulla» è un tracefile i cui percorsi vengono da un container o da un checkout CI (/build/src/a.c, /home/runner/work/repo/repo/src/a.c, C:\agent\_work\1\s\src\a.c) mentre lo spazio di lavoro ha src/a.c. Quando un caricamento lascia file senza corrispondenza, l'estensione cerca i nomi dei file nello spazio di lavoro, deduce la regola di prefisso che ne spiega il maggior numero, la registra come [FUCINI_REMAP_002], e il risultato del caricamento offre Apply Suggested Remap — un clic aggiunge la regola a fuciniCoverage.pathRemap e ricarica. Suggest Path Remap Rule esegue la stessa analisi su richiesta dalla palette. Nulla viene scritto senza il clic.

Un to può usare ${workspaceRoot}, che sta per la cartella dello spazio di lavoro in cui si trova il tracefile; in uno spazio di lavoro multi-root prova prima quella cartella, poi ogni altra cartella che risulta avere il file. Le regole stesse vengono lette per cartella, così ogni radice di uno spazio di lavoro multi-root può avere le proprie.

8. Coverage nell'editor

• Gutter e righello — per impostazione predefinita il gutter dell'editor stesso mostra solo i rilievi: barre MC/DC, triangoli «dall'ultima esecuzione», puntini sulle righe modificate. editorGutter.mode aggiunge barre solo sulle righe non coperte o una mappa di calore dei conteggi (sotto); la vista a colori di un intero file è l'Annotated Source.
• CodeLens di funzione — % di coverage sopra ogni funzione; clicca per saltare alla sua prima riga non coperta. Attiva/disattiva con codeLens.enabled.
• Hover su ramo e MC/DC — passa il mouse su una riga di decisione per i conteggi presi/non presi per ramo e una tabella vettoriale per condizione. Abilita una barra di margine colorata con mcdcGutter.enabled.
• Avvisi di codice morto — le funzioni con righe misurabili e copertura pari a zero sono segnalate nel pannello Problems (deadCode.enabled).
• Next / Previous Uncovered — salta tra le lacune.
• Barra di stato — un elemento $(dashboard) NN% a livello di esecuzione e uno per file, entrambi colorati in base al punteggio composito; passa il mouse per una tabella completa delle metriche.
• Badge dell'Esplora file — badge di copertura per file e per cartella, con il dettaglio per metrica al passaggio del mouse. Disattivati per impostazione predefinita: attivali con explorerBadges.enabled.
• Dall'ultima esecuzione — un triangolo rosso su ogni riga eseguita nell'esecuzione precedente e non in questa, uno verde per il caso inverso, con il righello panoramico e i conteggi al passaggio del mouse.
• Buffer modificati — ogni contrassegno, suggerimento e CodeLens si sposta con il testo mentre modifichi, e si ritira da una riga riscritta, dove un punto grigio dice perché.
• Conteggi dei colpi in linea — hitCounts.inline scrive ×12 dopo ogni riga su cui inizia un'istruzione, ×0 compreso: il numero che è sempre stato al passaggio del mouse, senza passarci il mouse. Toggle Inline Hit Counts lo alterna; il menu della barra di stato lo offre come Mostra o Nascondi, a seconda del caso.
• Voci per riga nel pannello Problems — problems.perLine mette una diagnostica di tipo Information, con una sottolineatura ondulata nell'editor, su ogni blocco contiguo di righe mai eseguite in un documento aperto (una funzione morta di quaranta righe è una voce, non quaranta) e, come uncoveredAndPartial, su ogni riga il cui arco di ramo non è mai stato preso. Le voci seguono le loro righe mentre modifichi e spariscono alla chiusura del documento; la voce per file dietro problems.enabled è invariata.
• Tinta di riga — lineHighlight mette una tinta traslucida dietro le righe stesse, per ciò che il margine segna (uncovered, oppure heatmap anche per le righe eseguite). Un’impostazione a sé, così il margine può restare pulito mentre i vuoti sono colorati, o viceversa.
• Righello di panoramica — overviewRuler decide la striscia nella barra di scorrimento indipendentemente dal margine: follow (con le barre, come prima), uncovered (sempre, così il margine può essere disattivato mentre la barra di scorrimento continua a mappare i vuoti) oppure off.
• Quale tracefile ha coperto una riga — con più report uniti, il suggerimento con il conteggio dei passaggi termina con Coperto da: e ogni report che ha coperto quella riga, compreso il nome della suite dal TN: di lcov; un clic su una riga di tracefile nella vista Coverage illumina le righe che ha contribuito in ogni editor aperto.

Screenshot pending — add assets/img/codelens-hover.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/codelens-crap.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/jump-between-gaps.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/explorer-badges.png (see SCREENSHOTS.md).

Modalità del gutter dell'editor

editorGutter.mode decide cosa mostra sulla copertura il gutter dell'editor stesso, oltre ai rilievi che mostra sempre. off (il predefinito) è solo quelli. uncovered mette una barra su ogni riga mai eseguita e una ambra su ogni riga con un arco di ramo mai preso, e nulla sulle righe coperte, così un muro verde non nasconde le tre rosse. coverage aggiunge una barra verde su ogni riga coperta, così l'intero file si legge in rosso, ambra e verde con i colori della scala cromatica. heatmap aggiunge invece una tinta calda su ogni riga eseguita, più intensa quanto più spesso è stata eseguita — mostra quante volte una riga è stata eseguita, non se è coperta, per cui un file al 100% lì va dal giallo al marrone, mai verde. Choose Editor Gutter Mode... ne sceglie una dalla palette o dal menu della barra di stato; il pulsante della modalità a destra nella barra di stato, o Alt+G, passa alla successiva con una sola pressione (statusBar.showModeToggle nasconde il pulsante). Entrambi scrivono l'impostazione. L'esempio attiva insieme le barre sulle righe non coperte e i conteggi in linea:

{
  "fuciniCoverage.editorGutter.mode": "uncovered",
  "fuciniCoverage.hitCounts.inline": true
}

Screenshot pending — add assets/img/gutters.png (see SCREENSHOTS.md).

La heatmap è relativa al file. La tonalità di una riga confronta il suo conteggio con quello della riga più calda dello stesso file, su scala logaritmica, in cinque gradini — così il corpo di un ciclo eseguito mille volte e una funzione eseguita due volte sono entrambi visibili, senza che l'uno sommerga l'altra, e un file in cui tutto è stato eseguito esattamente una volta risulta uniformemente caldo anziché uniformemente pallido. Con un tema scuro la scala va dall'oliva spento all'arancione vivo, con un tema chiaro dal giallo pallido al marrone: in entrambi i casi più colore significa più esecuzioni, e il rosso resta riservato alle righe mai eseguite. lineHighlight: "heatmap" stende le stesse tonalità dietro il codice come sfondo, e hitCounts.inline scrive il conteggio esatto dopo la riga.

{
  "fuciniCoverage.editorGutter.mode": "heatmap",
  "fuciniCoverage.lineHighlight": "heatmap",
  "fuciniCoverage.hitCounts.inline": true
}

Screenshot pending — add assets/img/heatmap-dark.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/heatmap-light.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/heatmap.gif (see SCREENSHOTS.md).

I colori li scegli tu. colorScale.lowColor, midColor e highColor danno il rosso, l'ambra e il verde del gutter, delle tinte di riga e di ogni percentuale; heatmap.colors e heatmap.colorsDark contengono le cinque tinte della heatmap per un tema chiaro e uno scuro, dalla riga eseguita meno volte a quella eseguita più volte. La pagina delle impostazioni mostra il risultato prima che venga salvato qualcosa: sotto Colour scale, un'anteprima resta visibile mentre le righe scorrono — il gradiente con i suoi due punti di snodo, alcune percentuali nei loro colori, e un piccolo editor chiaro e uno scuro colorati nella modalità coverage e nella heatmap — e si ridisegna non appena si sceglie un colore.

{
  "fuciniCoverage.heatmap.colors": ["#e3f2fd", "#90caf9", "#42a5f5", "#1e88e5", "#0d47a1"]
}

La parte di una riga che non è mai stata eseguita

Una riga è coperta oppure no, e la verità sta spesso nel mezzo: return x > hi ? hi : x; è stata eseguita, il suo ramo hi mai. Con lineHighlight attivo, la parte mai eseguita di una riga eseguita viene colorata nell'editor, per ogni formato che riporta gli intervalli di colonne (llvm-cov, Istanbul, Go, dotnet-coverage) — gli stessi intervalli che evidenzia Annotated Source. Solo sulle righe eseguite: una riga mai eseguita è già contrassegnata per intero. Un template C++ conta come eseguito là dove una qualsiasi istanziazione lo ha eseguito; che cosa abbia fatto ciascuna istanziazione è ciò che riporta la metrica delle istanziazioni.

Screenshot pending — add assets/img/partial-line.png (see SCREENSHOTS.md).

Quali test hanno eseguito questa riga

Alcuni report dicono non solo che una riga è stata eseguita, ma anche quali test l'hanno eseguita: coverage.py scritto con coverage json --show-contexts e dynamic_context = test_function in .coveragerc, OpenCover raccolto con -coverbytest, e un tracefile lcov scritto una sezione per test (TN:), le cui sezioni vengono sommate in un unico record con i test per riga. Passando il mouse sull'inizio di una riga, dove si trova il conteggio delle esecuzioni, i test vengono elencati — abbreviati a classe e metodo, i primi cinque per nome e gli altri come numero; il CodeLens della funzione dice quanti test l'hanno eseguita. Show Tests That Ran This Line — dalla Command Palette, dal menu contestuale dell'editor, in Visual Studio da Tools → Coverage Studio o con Ctrl+Shift+U, T — li elenca, dal più attivo in poi, e apre quello scelto dove è scritto nello spazio di lavoro. Un'esecuzione dotnet test non sa dire quale test ha eseguito cosa; impostate testRun.perTest e Run Tests with Coverage elenca le classi di test e le esegue una alla volta, ogni report contrassegnato con la sua classe, così l'hover, il lens e il comando possono rispondere anche per .NET. L'informazione è conservata per file, quindi sopravvive all'unione con un report che dei test non sa nulla.

{
  "fuciniCoverage.testRun.perTest": true
}

# .coveragerc
[run]
dynamic_context = test_function

coverage run -m pytest && coverage json --show-contexts

Screenshot pending — add assets/img/tests-per-line.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/tests-for-line.gif (see SCREENSHOTS.md).

Superato o fallito, sui segni

Una riga coperta ha lo stesso aspetto, che il suo test sia passato o no. Dove il report dice quali test hanno eseguito una riga e il file dei risultati del runner dice come sono finiti, una riga eseguita da un test fallito riceve una barra rossa al suo inizio e una striscia nel righello di panoramica; il suo hover nomina i test falliti, e Show Tests That Ran This Line scrive fallito accanto a ciascuno. Quando un test è rosso, il posto in cui guardare è il codice che ha attraversato. I risultati vengono letti a ogni caricamento dalla cartella di ciascun report — qualsiasi .trx, e i nomi usati dagli strumenti che scrivono JUnit (TEST-*.xml, junit*.xml, test-results*.xml) — e da testResults.paths, come percorsi o glob relativi alla cartella. Run Tests with Coverage chiede a dotnet test un test-results.trx accanto al report, così con testRun.perTest attivo non c'è nulla da configurare. testResults.enabled disattiva questa lettura.

{
  "fuciniCoverage.testResults.paths": ["build/test-results/**/*.xml", "reports/junit.xml"]
  }

Screenshot pending — add assets/img/pass-fail.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-pass-fail.gif (see SCREENSHOTS.md).

I test che una modifica tocca

Un'esecuzione completa risponde lentamente a ciò a cui Run Tests Affected by My Changes… risponde subito: fra tutti i test, quali sono passati per il codice che ho appena modificato? A git viene chiesto il diff dell'albero di lavoro rispetto a testImpact.baseRef — HEAD per impostazione predefinita, cioè ciò che non è ancora in un commit; origin/main per tutto ciò che il ramo cambia — e vengono elencati i test che hanno eseguito una riga modificata, per primo quello che ha eseguito la parte maggiore della modifica. Scegliere un test lo apre. Dove i report provengono da un'esecuzione per test (testRun.perTest), la prima voce esegue solo quei test, ogni classe nel proprio report, così il report di tutte le altre classi resta valido e i totali restano quelli dell'intera suite. Viene elencato anche un test che ha eseguito solo righe sotto un inserimento o una rimozione: altrimenti il suo report nominerebbe le righe sbagliate.

Screenshot pending — add assets/img/test-impact.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-test-impact.gif (see SCREENSHOTS.md).

Il minor numero di test che eseguono ancora ogni riga

Show Minimal Test Set… risponde a due domande a partire dalle stesse righe per test: quali pochi test eseguirebbero ancora ogni riga che la suite esegue — per l'esecuzione rapida prima di un commit — e quali test non eseguono alcuna riga che un altro non esegua già. I test scelti vengono per primi, ciascuno con le righe che aggiunge e le righe che esegue solo lui; poi gli altri, ciascuno segnato come uno che non aggiunge nulla. La scelta è quella greedy — il test che esegue più righe, poi quello che ne aggiunge di più a quelle — quindi è vicina all'insieme più piccolo ed è la stessa ogni volta. Ridondante per righe non vuol dire ridondante per ciò che un test verifica: un test che non aggiunge alcuna riga può comunque essere l'unico a verificare un valore su quelle righe. L'elenco dice dove guardare quando si sfoltisce una suite, mai che cosa eliminare.

Screenshot pending — add assets/img/minimal-test-set.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-minimal-test-set.png (see SCREENSHOTS.md).

Eseguire questo test, con la coverage

Mettete il cursore in un test ed eseguite Run This Test with Coverage — dalla Command Palette, dal menu contestuale dell'editor, in Visual Studio da Tools → Coverage Studio o con Ctrl+Shift+U, R — e quel solo test viene eseguito con la coverage attiva: il metodo di test in cui sta il cursore, oppure la classe di test o il blocco describe quando è tra un metodo e l'altro, oppure il file quando è sopra ogni classe. Ciò che sta sotto il cursore viene letto dal testo, quindi funziona per C#, VB e F# ([Fact], [Test], [TestMethod] e simili), JavaScript e TypeScript (it, test, describe) e Python (def test_…), qualunque servizio di linguaggio sia installato. La ricetta della cartella viene ristretta a esso — dotnet test --filter "FullyQualifiedName~…", jest o vitest <file> -t "…", un node id di pytest — e ciò che ha scritto viene caricato come qualsiasi esecuzione; un runner che non si può restringere lo dice, e Run Tests with Coverage li esegue tutti.

Screenshot pending — add assets/img/run-this-test.gif (see SCREENSHOTS.md).

Go e Rust. In un file Go il func TestXxx (o Fuzz…, Example…) in cui sta il cursore viene eseguito da solo, nel proprio package e con il suo nome esatto — go test ./pkg/calc -run "^TestTotal$" — e fuori da un test viene eseguito il package del file. In un file Rust la funzione #[test] viene eseguita tramite il suo percorso nel crate con --exact; con il cursore in un mod e in nessun test, vengono eseguiti i test di quel modulo; un test di integrazione sotto tests/ viene eseguito nel proprio binario (--test api). A un runner vengono passati solo file del suo linguaggio: un file TypeScript in una cartella Go ottiene una frase, non un'esecuzione di nulla.

La coverage dopo ogni salvataggio

Con testRun.onSave attivo, salvare un sorgente esegue i test che lo coprono, con la coverage, un istante dopo il salvataggio, e il gutter segue. Per una soluzione .NET il progetto del file salvato viene trovato attraverso il grafo dei .csproj e vengono eseguiti solo i progetti di test che lo referenziano — direttamente, o attraverso altri progetti — un dotnet test <project> ciascuno; qualunque altro runner esegue la sua ricetta intera; un file che nessun progetto possiede e nessun report misura non esegue nulla. Più salvataggi di seguito sono una sola esecuzione, e un'esecuzione già in corso non viene interrotta. Il resto è come lo fa Run Tests with Coverage: il terminale, il riquadro Output, il report caricato. Disattivato per impostazione predefinita — è un'abitudine da scegliere, non un predefinito da scoprire.

{
  "fuciniCoverage.testRun.onSave": true
}

Screenshot pending — add assets/img/coverage-on-save.gif (see SCREENSHOTS.md).

L'app stessa, con la coverage

Un'esecuzione di test dice ciò che i test raggiungono. Ciò che raggiunge una persona — facendo clic fra le schermate prima di un rilascio, ripetendo i passi di un cliente — è anch'esso coverage, e Run App with Coverage… lo raccoglie. L'app .NET della cartella — un Exe, un WinExe, un progetto web o worker, mai un progetto di test; una scelta dove ce n'è più d'una — viene avviata sotto dotnet-coverage di Microsoft in una console tutta sua, così che in un'app console si possa digitare, e resta in esecuzione finché non la chiudete. Ciò che avete percorso viene poi caricato come qualsiasi esecuzione, e in una sessione di coverage si aggiunge a ciò che i test hanno eseguito. Come l'app è terminata non conta contro l'esecuzione. Lo strumento va installato una volta: dotnet tool install --global dotnet-coverage.

Screenshot pending — add assets/img/run-app.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-run-app.gif (see SCREENSHOTS.md).

I mutanti, e dove si trovano

Uno strumento di mutation testing — PIT per Java, Stryker per JavaScript, C# e Scala, Mull per C e C++ — modifica il codice in piccoli punti ed esegue i test contro ogni modifica. Una modifica che nessun test nota è un mutante sopravvissuto: il codice è stato eseguito, e niente ha verificato che cosa abbia fatto. Il punteggio di mutazione dice quanti sono stati individuati; dalla versione 0.2026.83 l'editor dice dove si trovano gli altri. Una riga che ne contiene uno porta una nota in coda (⚑ 2 mutants survived), il testo modificato è sottolineato quando il report indica di quale testo si trattava (lo fanno Stryker e Mull), il righello di panoramica ha una striscia, e al passaggio del mouse si vede che cosa è stato modificato, quanti test lo hanno eseguito e, per i mutanti individuati, quale test li ha individuati.

Screenshot pending — add assets/img/mutant-hover.png (see SCREENSHOTS.md).

Sopravvissuto significa che i test hanno eseguito il codice modificato e sono tutti passati. Non testato (il no coverage del report) significa che nessun test esegue quel codice, quindi niente avrebbe potuto accorgersene. I mutanti individuati vengono contati al passaggio del mouse e mai contrassegnati, e i mutanti che non sono mai stati una prova equa — uno che non compilerebbe — restano fuori dal punteggio. Annotated Source ha una riga sotto ciascuna di queste righe e un pulsante Next Mutant (U), e i report HTML hanno una sezione Surviving Mutants con il collegamento alla riga. Non c'è nulla da attivare, e un progetto senza report di mutazione non ne vede niente.

Screenshot pending — add assets/img/mutants.gif (see SCREENSHOTS.md).

Un test se ne accorgerebbe? Un'esecuzione di mutazione sotto il cursore

L'esecuzione di mutazione di un progetto richiede un'ora; quella di una funzione, un minuto. Run Mutation Tests Here esegue quel minuto: la funzione in cui sta il cursore — o le righe selezionate, o il file — è ciò che al runner di mutazione della cartella viene detto di mutare, e il suo report viene caricato accanto alla coverage sullo schermo, dove i mutanti sopravvissuti sono segnati. Per C# è Stryker.NET (dotnet tool install --global dotnet-stryker), a cui vengono indicati l'intervallo di caratteri e il progetto di test che referenzia il progetto del file; per JavaScript e TypeScript StrykerJS, a cui vengono indicate le righe; per Java PIT con Maven, a cui viene indicata la classe. Come il runner è terminato non conta contro l'esecuzione: un punteggio sotto la sua soglia è un codice di uscita, e resta un report. Un runner che non ha scritto nulla viene segnalato, con ciò che gli serve installato.

Screenshot pending — add assets/img/mutation-here.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-mutation-here.gif (see SCREENSHOTS.md).

La vista Test Coverage di VS Code stesso

Con testCoverage.publish attivo (il predefinito), ogni esecuzione caricata va anche alla vista Test Coverage nativa dell'editor — il pannello di copertura del Test Explorer, le percentuali per file che mette nell'Explorer, e l'interruttore Show Inline Coverage dell'editor stesso — come righe, archi di ramo e funzioni, con i dettagli caricati su richiesta, da qualunque tracefile provengano e senza alcun adattatore di test di mezzo. Show in Test Coverage View pubblica l'esecuzione attiva e apre il pannello qualunque cosa dica l'impostazione; il menu della barra di stato lo offre dietro quickActions.showTestCoverage. Disattivato, nel Test Explorer non compare alcuna voce Fucini Coverage. Quando un file di traccia nomina i suoi test (le sezioni TN: di lcov), ogni test compare sotto Fucini Coverage nel Test Explorer e la vista può filtrare la copertura di un file per test.

Screenshot pending — add assets/img/test-coverage-view.png (see SCREENSHOTS.md).

Righe non coperte nel pannello Problems

Disattivato per impostazione predefinita perché rumoroso per natura, e solo per i documenti aperti — un'esecuzione da duemila file non può inondare il pannello. Indipendente da problems.enabled, che si limita a una voce per file:

{
  "fuciniCoverage.problems.perLine": "uncoveredAndPartial"
}

Screenshot pending — add assets/img/problems-panel.png (see SCREENSHOTS.md).

9. Coverage differenziale

Limita le decorazioni alle righe modificate rispetto a un riferimento base git — ideale per rivedere esattamente cosa una PR ha coperto o meno:

{
  "fuciniCoverage.gitDiff.enabled": true,
  "fuciniCoverage.gitDiff.baseRef": "origin/main"
}

Screenshot pending — add assets/img/diff-coverage.png (see SCREENSHOTS.md).

Un gate sul codice nuovo

threshold.newCode è un gate a sé, accanto a quelli sull'intera esecuzione: delle righe modificate rispetto a gitDiff.baseRef che si possono misurare, la percentuale minima che deve essere stata eseguita. Un progetto al 62% complessivo può comunque chiedere che ciò che viene scritto oggi sia testato. Viene calcolato a ogni caricamento sull'intera esecuzione, che resta sullo schermo — gitDiff.enabled è un'altra cosa: le righe modificate al posto dell'esecuzione. Check Coverage Thresholds e le voci di conformità in Problems lo danno per fallito in una frase tutta sua: New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran). Una modifica senza alcuna riga misurabile — commenti, un README — non fa fallire nulla.

{
  "fuciniCoverage.threshold.newCode": 80,
  "fuciniCoverage.gitDiff.baseRef": "origin/main"
  }

Screenshot pending — add assets/img/new-code-gate.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-new-code-gate.png (see SCREENSHOTS.md).

Codice nuovo per tag, per autore, per data

Il codice nuovo sono, per impostazione predefinita, le righe che l'albero di lavoro cambia rispetto a gitDiff.baseRef — un ramo, un commit o un tag: "v1.4.0" è tutto ciò che è venuto dopo quel rilascio. Due impostazioni chiedono ciò che un riferimento git non può. gitDiff.author prende parte del nome di un autore, e il codice nuovo sono allora le righe che git attribuisce a quell'autore; gitDiff.since prende un giorno, e sono le righe modificate per l'ultima volta in quel giorno o dopo, qualunque sia il ramo da cui sono arrivate; entrambe insieme, le righe di quell'autore da quel giorno. Si basano su git blame, un file alla volta — cosa che un'esecuzione grande sentirà a ogni caricamento — e prendono il posto del diff per la coverage del diff e per il gate qui sopra. Una riga non ancora in un commit conta in entrambi i casi.

{
  "fuciniCoverage.gitDiff.author": "Ada",
  "fuciniCoverage.gitDiff.since": "2026-09-01"
  }

Screenshot pending — add assets/img/new-code-author.png (see SCREENSHOTS.md).

Modifiche indirette: ciò che si è mosso senza che nessuno lo toccasse

Un diff dice quali righe sono cambiate; due esecuzioni dicono quali righe hanno smesso o iniziato a essere eseguite. Le righe che meritano uno sguardo sono quelle in cui i due discordano: codice che nessuno ha modificato e che non viene più eseguito, perché un test è stato eliminato, perché un ramo a monte ora ritorna prima, perché una fixture è cambiata. Una revisione del diff non può vederle — ne sono fuori per definizione. Show Indirect Coverage Changes… le elenca per file, per primo il file che ha perso di più, e apre quello che scegliete alla sua prima riga di questo tipo. L'esecuzione viene confrontata con la baseline CI dove baseline.report ne indica una — che è ciò su cui viene giudicata una pull request — e altrimenti con l'esecuzione precedente; le righe che l'albero di lavoro cambia rispetto a gitDiff.baseRef, e tutto ciò che sta sotto un punto in cui quella modifica sposta le righe del file, vengono lasciati fuori.

Screenshot pending — add assets/img/indirect-changes.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-indirect-changes.png (see SCREENSHOTS.md).

10. Il punteggio composito

Invece di riportare sei numeri, l'estensione li combina in un'unica Media Armonica Ponderata (WHM). Per metriche con percentuali pᵢ e pesi wᵢ:

WHM = ( Σ wᵢ ) / ( Σ wᵢ / pᵢ )

Una media armonica è dominata dal suo termine più piccolo, quindi una metrica debole non può essere mascherata da una perfetta — esattamente la proprietà che vuoi da un gate di sicurezza. Pesi predefiniti:

Imposta un peso a 0 per escludere quella metrica dal punteggio. Le metriche non presenti nei dati (ad es. MC/DC in una semplice esecuzione lcov) vengono semplicemente omesse.

Il codice oggetto e il punteggio di mutazione pesano 0 finché non si decide diversamente (whmWeights.objectCode, whmWeights.mutation). La copertura del codice oggetto comprende già la copertura delle istruzioni, quindi pesarle entrambe conta due volte la stessa evidenza; un punteggio di mutazione non è affatto copertura — una suite di test può eseguire ogni riga e non rilevare nulla. Entrambi hanno comunque una colonna propria e una soglia propria.

Screenshot pending — add assets/img/score-weights.svg (see SCREENSHOTS.md).

Copertura delle condizioni

a && b è una decisione — due rami — e due condizioni con quattro esiti. Una suite può percorrere entrambi i rami e non vedere mai b falso: la copertura dei rami è completa e la copertura delle condizioni è tre su quattro. Questo livello si colloca tra la copertura dei rami e MC/DC in DO-178C e ISO 26262, e dalla versione 0.2026.83 è una metrica a sé anziché essere inglobata nei rami: una riga nelle schede della barra di stato, una colonna nella vista Coverage, nei report e nelle esportazioni, un peso di 3 nel punteggio (whmWeights.conditions) e un gate (threshold.conditions; nessun gate con il profilo standard, 100 con safety).

Screenshot pending — add assets/img/branch-condition-mcdc.svg (see SCREENSHOTS.md).

Lette dalle sonde condition di BullseyeCoverage, da un'esportazione cond di TRACE32 e da GCC 14 compilato con -fcondition-coverage. Un report che non distingue le condizioni dalle decisioni non ha né riga, né colonna, né peso di questo tipo. Se si usa Bullseye o TRACE32: le condizioni finora contavano come rami, quindi con questa versione la percentuale dei rami cambia e, con il nuovo peso, anche il punteggio composito; impostare whmWeights.conditions su 0 per avere il punteggio com'era.

GCC 14, riga per riga. -fcondition-coverage fa dire a gcov quale esito di quale condizione manca — la condizione 1 mai vera, la condizione 0 mai né vera né falsa — e ogni condizione è segnata sulla sua riga e nominata nell'hover, dal JSON di gcov come dal suo listato testuale (condition outcomes covered 3/6). La metrica sta dove stanno le altre: threshold.conditions le fa da gate e resta non giudicato dove un'esecuzione non ha quel valore, Copy Coverage Summary ha una colonna Conditions, badge.metric accetta conditions, e la casella di ricerca accetta conditions < 80. Il valore dei rami di una funzione lascia fuori gli esiti delle sue condizioni, come quelli del file e dell'esecuzione.

Screenshot pending — add assets/img/gcc-conditions.png (see SCREENSHOTS.md).

Complessità e CRAP

Alcuni report contengono la complessità ciclomatica di ogni funzione: OpenCover (che è ciò che scrive Coverlet), JaCoCo, Clover e Cobertura. In tal caso l'estensione calcola un punteggio CRAP — Change Risk Anti-Patterns — per la funzione, a partire da quella complessità e dalla copertura che essa stessa ha misurato:

CRAP = complexity² × (1 − coverage)³ + complexity

Una funzione semplice e completamente testata ottiene come punteggio la propria complessità e nulla più; una funzione complessa e appena testata arriva a diverse centinaia. Nell'esempio C# del progetto dimostrativo Price() ha complessità 22 e circa il 37% delle righe coperte, il che dà 142.2, mentre Shipping() ha complessità 12 ed è completamente coperta, il che dà 12. Il limite consueto è 30: una funzione che lo raggiunge o lo supera è elencata sotto Riskiest Methods nel report HTML, a partire dalla peggiore.

Screenshot pending — add assets/img/crap-curve.svg (see SCREENSHOTS.md).

La complessità e il punteggio compaiono nel CodeLens della funzione e accanto alla funzione nel sorgente annotato. Max CRAP è il punteggio più alto fra tutte le funzioni di un file — il peggiore, non una media — ed è una colonna nella vista Coverage, nel report HTML e nelle esportazioni CSV e Markdown. È un'informazione: non ha soglia né peso nel punteggio composito. I report che non contengono la complessità (lcov, gcov, Istanbul, coverage.py) non hanno CRAP, e nemmeno una colonna vuota.

Dalla versione 0.2026.83 lo hanno anche C e C++. llvm-cov non riporta alcuna complessità, quindi viene calcolata dai dati sui rami che il report già contiene: le condizioni scritte nel file della funzione stessa, più uno — la definizione di McCabe, ed è ciò che gli strumenti a livello di sorgente contano per .NET e Java. Le condizioni uscite da una macro di un altro file, ogni assert per esempio, non vengono contate.

Screenshot pending — add assets/img/riskiest-methods.png (see SCREENSHOTS.md).

Risk hotspots, e quali file mostrare

Sotto l'albero della vista Coverage, Risk hotspots elenca le funzioni dove il codice complesso incontra poca coverage, dalla peggiore in poi, ciascuna apre il suo file alla funzione. Una funzione si qualifica per punteggio CRAP — hotspots.crapThreshold, 30 per impostazione predefinita, la cifra proposta dagli autori della metrica — o per la sola complessità ciclomatica, hotspots.complexityThreshold, disattivata per impostazione predefinita; solo i report che riportano la complessità (OpenCover, Cobertura di Coverlet, JaCoCo, llvm-cov) ne hanno. Community vede il conteggio e il punteggio peggiore; l'elenco ordinato è Pro. Accanto all'ordinamento, un secondo menu a discesa dice quali file mostra l'albero — tutti, i file con lacune, i file non testati, o i file cambiati dall'ultima esecuzione; le cartelle seguono i loro file e conservano i propri numeri. Entrambi sono anche in Visual Studio, nella finestra Coverage.

Screenshot pending — add assets/img/vs-hotspots.png (see SCREENSHOTS.md).

Namespace, classi e metodi

Per un report .NET che nomina le sue classi — Cobertura e il coverage.cobertura.xml di Coverlet, OpenCover — un terzo menu a discesa, Folders / Namespaces, disegna la stessa esecuzione come namespace, classi e metodi: il numero di un namespace è la somma di quelli delle sue classi, quello di una classe dei suoi metodi, esattamente come quello di una cartella è dei suoi file, con lo stesso ordinamento e lo stesso filtro. Una riga di metodo apre il file al metodo; una classe dichiarata in nessun namespace sta sotto (no namespace). La scelta viene scritta in coverageView.perspective; un'esecuzione che non porta nomi di classe non ha il menu a discesa e mostra le sue cartelle. In Visual Studio la finestra Coverage ha lo stesso menu a discesa.

Screenshot pending — add assets/img/namespace-perspective.png (see SCREENSHOTS.md).

Cercare nell'albero

Sotto i pulsanti e i menu a discesa, una casella di ricerca. Una parola tiene le righe il cui nome o percorso la contiene — ogni parola digitata deve esserci; un confronto tiene le righe la cui cifra lo soddisfa — < 80% sul punteggio, lines >= 90, branches = 0, functions != 100, mcdc < 50 — e invoice < 80 vuole entrambe le cose. Le righe di metodo della prospettiva per namespace e i risk hotspot vengono cercati insieme ai file, così una funzione si trova dove l'esecuzione la tiene. L'albero viene filtrato mentre digitate, nella pagina, senza ridisegnarlo; una cartella che contiene una corrispondenza si apre per essa e si richiude quando la casella si svuota; Esc la cancella. La stessa casella, la stessa grammatica, in Visual Studio.

Screenshot pending — add assets/img/tree-search.gif (see SCREENSHOTS.md).

L'albero segue l'editor

Il file che state guardando viene evidenziato nella vista Coverage, le cartelle sopra di esso vengono aperte e la sua riga viene portata in vista scorrendo — non occorre più cercare nell'albero il file che è già aperto. Per il resto l'albero mantiene la sua posizione di scorrimento, e nulla viene ridisegnato. coverageView.followActiveEditor, attivo per impostazione predefinita, lo disattiva per chi preferisce lasciare l'albero dove l'ha messo.

Screenshot pending — add assets/img/follow-editor.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-follow-editor.gif (see SCREENSHOTS.md).

11. Gating di conformità

Il verdetto COMPLIANT / NON-COMPLIANT (mostrato nella vista sorgente annotata, nel report HTML ed entrambi gli hover della barra di stato) è determinato da soglie per metrica e una modalità:

Screenshot pending — add assets/img/statusbar.png (see SCREENSHOTS.md).

Una soglia di 0 disattiva quel gate, e una metrica che il report non contiene non viene mai giudicata. Che cosa vale una soglia non impostata lo decide il profilo descritto più sotto. Esegua Fucini Coverage: Check Coverage Thresholds per valutare su richiesta.

Screenshot pending — add assets/img/vs-error-list.png (see SCREENSHOTS.md).

Profili delle soglie

threshold.profile stabilisce che cosa vale una soglia che non è stata impostata. standard, il valore predefinito dalla versione 0.2026.82, è ciò che si può esigere da un progetto ordinario non legato alla sicurezza funzionale. safety porta ogni gate a 100 — ciò che richiede un safety case, ed esattamente ciò che veniva distribuito fino alla versione 0.2026.81.

Una soglia impostata esplicitamente prevale su entrambi i profili. L'esempio fissa il gate dei rami a 90 e tutto il resto a 100; per esigere 100 solo da alcune metriche, si resti su standard e si impostino quelle manualmente. Un'avvertenza deriva dal funzionamento delle impostazioni: un valore uguale a quello predefinito di fabbrica non è distinguibile dall'assenza di valore, perciò con safety una soglia scritta esattamente con la sua cifra standard — 80 per le righe, ad esempio — conta comunque come 100.

{
  "fuciniCoverage.threshold.profile": "safety",
  "fuciniCoverage.threshold.branch": 90
}

Screenshot pending — add assets/img/threshold-profile.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/threshold-profiles.gif (see SCREENSHOTS.md).

Se faceva affidamento sui vecchi valori predefiniti, dopo l'aggiornamento alla versione 0.2026.82 il giudizio sarà più indulgente finché non seleziona safety. Un'installazione già in uso in precedenza ne viene informata una sola volta, con un pulsante Keep 100% (safety) che scrive il profilo nelle impostazioni utente; per un progetto condiviso lo inserisca anche nelle impostazioni dell'area di lavoro, in modo che tutti siano giudicati allo stesso modo. Configure Coverage Compliance & Thresholds... presenta il profilo sopra la griglia delle soglie, e la sua anteprima in tempo reale giudica con i gate effettivamente in vigore. In ogni scheda e report, una metrica il cui gate è disattivato mostra la propria cifra con un trattino neutro anziché un segno di spunta o una croce.

Screenshot pending — add assets/img/statusbar-metrics.png (see SCREENSHOTS.md).

11a. Coverage del codice oggetto

Ogni altra metrica qui si misura dal sorgente: uno strumento instrumenta il codice, la build instrumentata gira e i contatori dicono quali istruzioni, rami o condizioni sono stati esercitati. La coverage del codice oggetto misura altro — quanta parte del binario costruito è stata davvero eseguita, contata in byte di istruzioni, osservando il flusso di istruzioni anziché instrumentando il sorgente. Conta perché un compilatore emette codice di cui nessuna riga del vostro sorgente rende conto: controlli sui limiti degli array, tabelle di salto di switch, salvataggi di registri, sonde di stack, chiamate a routine di supporto del runtime per divisione o virgola mobile su core privi dell'istruzione. È anche l'unica metrica qui che risponde a questo copre l'assembly? — l'assembly scritto a mano non viene mai instrumentato e uno strumento basato sul sorgente non lo raggiunge. DO-178C dice esplicitamente perché: al livello A, dove un compilatore o un linker genera codice non direttamente tracciabile alle istruzioni sorgente, l'obiettivo 6.4.4.2b richiede una verifica aggiuntiva proprio di quel codice generato.

Sussume la coverage delle istruzioni: ogni istruzione macchina eseguita proviene da un'istruzione sorgente, quindi il 100% di coverage del codice oggetto implica il 100% di coverage delle istruzioni. Il contrario non vale, e proprio quell'asimmetria è il motivo per misurarla. Ne seguono due cose. Non ha alcun peso nel punteggio composito, perché mediare due misure delle stesse esecuzioni conta due volte la stessa prova; è invece controllata da fuciniCoverage.threshold.objectCode, un requisito anziché un peso, che è come la norma la richiede. E il divario è ciò che conta: un'esecuzione al 100% di coverage delle righe con meno del 100% di coverage del codice oggetto ha individuato esattamente il codice generato dal compilatore di cui il vostro sorgente non rende conto, perciò la scheda di conformità dice 312 byte mai eseguiti, con 100% di coverage delle righe invece di seppellirlo come «94%». Il contrario — un intero binario dato per eseguito mentre il suo sorgente no — è una contraddizione, non un punteggio basso: quasi sempre un tracefile obsoleto da un lato di una fusione, o nomi di moduli che non hanno mai corrisposto ai percorsi dei file. Viene segnalato come rilievo.

La coverage del codice oggetto richiede che il binario giri dove le sue istruzioni possano essere osservate. Ci sono tre strade e differiscono enormemente per costo. Solo la terza produce coverage del codice oggetto; le prime due sono qui perché risolvono un problema affine, spesso quello che conviene davvero risolvere.

1. Una build instrumentata, in esecuzione sul target. I cross-compilatori GCC accettano -fprofile-arcs -ftest-coverage, quindi l'instrumentazione che funziona su una workstation funziona sul target — salvo che un sistema bare-metal non ha un filesystem su cui scrivere i contatori .gcda e spesso non ha un exit() in cui scriverli. I contatori stanno comunque in RAM, quindi la soluzione è scaricare quella memoria e ricostruire i file fuori dal target; embedded-gcov del JPL della NASA (Apache-2.0) fa esattamente questo, senza filesystem, sistema operativo o libreria C standard. Si ottiene coverage di istruzioni, rami e funzioni di una build prodotta dal vostro cross-compilatore, per il vostro set di istruzioni, sul vostro hardware — non coverage del codice oggetto, e il binario misurato è instrumentato, quindi più grande e più lento di quello che spedite. Caricate il risultato come LCOV, gcovr JSON, gcov JSON o, su una toolchain anteriore a GCC 9, come il listato in testo semplice .gcov.
2. Un simulatore del set di istruzioni. Eseguite il vero binario target in un simulatore e ricavate la coverage dagli indirizzi eseguiti: niente hardware, niente instrumentazione, nessuna sonda e, poiché osserva istruzioni, può produrre vera coverage del codice oggetto. Il limite è la fedeltà: un simulatore modella bene il core e meno bene le periferiche, quindi trattate con sospetto i risultati di sistema completo a meno che non modelli da vicino il vostro silicio.
3. Trace on-chip e un debugger. La via di livello certificativo, e l'unica davvero non intrusiva: l'unità di trace del core riporta il flusso di istruzioni a un debugger, che lo trasforma in coverage. Nulla viene instrumentato, la dimensione del codice non cambia e i tempi non sono alterati — ed è questo che rende il risultato una prova sul binario che spedite davvero. Verificate il silicio prima di metterlo a budget: in molte famiglie di microcontrollori il trace completo esiste solo su una variante di emulazione o sviluppo, con un ampio buffer di trace e una porta veloce, mentre i pezzi di produzione espongono un'unità di trace ridotta, il cui ripiego offerto dal fornitore è un trace software che instrumenta il codice e consuma tempo di CPU — eliminando proprio la proprietà per cui quella via era stata scelta.

Molti progetti embedded misurano la coverage compilando gli stessi sorgenti per la macchina di sviluppo ed eseguendo lì gli unit test. È veloce, non richiede hardware, ed è la scelta predefinita giusta per la maggior parte dei team — ma vale la pena essere chiari su cosa descriva davvero quella prova: un compilatore diverso, un ottimizzatore diverso, un set di istruzioni diverso e un binario diverso da quello che si spedisce. Per la maggior parte del software è un compromesso accettabile e ben compreso. Per lavori valutati secondo IEC 61508, ISO 26262 o DO-178C è la classica obiezione host-contro-target, e le vie sopra sono le risposte classiche: la prima la chiude per la coverage del sorgente, la terza per il codice oggetto.

Oggi l'export letto per il codice oggetto è quello di COVerage.EXPORT.ListModule di Lauterbach TRACE32 con metric="object"; caricatelo come qualsiasi altro tracefile. Questa metrica viene valutata e controllata solo con una licenza a pagamento e durante il periodo di valutazione. Un'installazione Community non la valuta — ma viene informata quando un tracefile la contiene, perché un verdetto di conformità che omettesse silenziosamente la prova più forte nel file sarebbe peggiore di uno che dice cosa ha omesso.

12. Esclusione delle righe non di codice

Con excludeComments attivo (predefinito), le istruzioni che cadono interamente su righe solo commento o vuote sono escluse dai totali — questo neutralizza anche una nota particolarità di llvm-cov/gcov in cui un conteggio dei colpi vagante finisce su un commento. Sono rispettati anche i marcatori standard:

x = risky();          // LCOV_EXCL_LINE
// LCOV_EXCL_START
debug_only_block();
// LCOV_EXCL_STOP

Anche le direttive del preprocessore non contano come codice, in C, C++, Objective-C, CUDA e C#: una riga che inizia con # — #define, #include, #if — e le righe su cui la prosegue una barra rovesciata finale. gcov attribuisce ogni uso di una macro alla riga in cui è definita, così un header la cui unica riga riportata era #define CHANNEL_COUNT (33U) risultava coperto al 100% perché un ciclo nel file .c arrivava fino a quel valore, e uno la cui costante nessuno usava risultava allo 0%. Un header del genere ora non ha nulla da misurare e non viene elencato.

Imposta excluded.includeInTotals su true per contare comunque le righe escluse.

Lasciare fuori un file o una cartella, dall'albero

Fate clic destro su un file o una cartella nella vista Coverage e scegliete Exclude from Coverage — è anche tra le azioni di percorso della riga — oppure eseguite Exclude This File from Coverage sul file aperto: il percorso del file relativo allo spazio di lavoro, o il /** della cartella, va in fuciniCoverage.ignore nelle impostazioni della cartella, una volta sola, e il ricaricamento lo toglie da ogni totale e da ogni pagina; il pattern è lì per poter essere tolto di nuovo. In Visual Studio il menu della riga e Tools → Coverage Studio hanno gli stessi due comandi, che scrivono la stessa impostazione nello stesso file.

Screenshot pending — add assets/img/exclude-from-tree.gif (see SCREENSHOTS.md).

Attributi e namespace, per .NET

Due impostazioni leggono dal sorgente ciò che il report non sa dire. ignore.attributes — ExcludeFromCodeCoverage per impostazione predefinita — esclude la classe, il metodo o la proprietà sotto un attributo che nomina, come farebbero LCOV_EXCL_START/STOP, qualunque strumento abbia scritto il report: Coverlet rispetta l'attributo, OpenCover, dotCover e un lcov convertito no, e ora tutti concordano. Nomi con o senza il suffisso Attribute, con o senza namespace; aggiungete GeneratedCode, Obsolete o i vostri. ignore.namespaces lascia fuori ogni file la cui dichiarazione di namespace corrisponde a un prefisso, con * come jolly — Acme.Generated, Acme.*.Migrations, *Tests — e il riquadro Output nomina i file che ha tolto. Entrambe vengono lette nello stesso passaggio che legge i marcatori nei commenti, in entrambe le edizioni.

{
  "fuciniCoverage.ignore.attributes": ["ExcludeFromCodeCoverage", "GeneratedCode"],
  "fuciniCoverage.ignore.namespaces": ["Acme.Generated", "*.Migrations"]
}

Escludere dall'editor

Selezionate le righe e prendete Exclude Selection from Coverage dalla lampadina, dal menu contestuale dell'editor o dalla Command Palette — in Visual Studio dalla lampadina (Ctrl+.), dal menu del clic destro della finestra di codice, da Tools → Coverage Studio o con Ctrl+Shift+U, X — e l'esclusione viene scritta dove sta il codice: [ExcludeFromCodeCoverage] sopra una classe, un metodo o una proprietà C#, VB o F#, con il nome breve quando il file importa già System.Diagnostics.CodeAnalysis e con il nome completo quando non lo importa, così che non si debba aggiungere alcuno using; LCOV_EXCL_LINE alla fine di una sola riga di codice; LCOV_EXCL_START e LCOV_EXCL_STOP attorno a più righe, all'indentazione della prima — con il segno di commento del linguaggio, //, #, ', -- o ;. Un solo passo di annullamento. La lampadina lo offre anche su una riga che le voci di Problems segnano come non coperta. Una riga già marcata, o un membro già attribuito, viene lasciato com'è.

Screenshot pending — add assets/img/exclude-selection.gif (see SCREENSHOTS.md).

Solo i rami, e i marcatori di gcovr

Un else difensivo, un default: che nessun valore raggiunge, l'arco che un compilatore aggiunge per un'eccezione: la riga viene eseguita e deve contare, e solo il suo ramo non può essere preso. LCOV_EXCL_BR_LINE e LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP tolgono dal conteggio i rami sulle loro righe e vi lasciano le righe. LCOV_EXCL_EXCEPTION_BR_LINE e la sua regione tolgono ancora meno — solo gli archi percorsi da un'eccezione, dove il report dice quali sono, come fa il JSON di gcov. Ogni marcatore viene letto anche con i prefissi di gcovr: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOVR_EXCL_BR_LINE, GCOV_EXCL_STOP e gli altri significano ciò che significano quelli LCOV_EXCL_, così un sorgente scritto per gcovr si legge qui allo stesso modo, qualunque strumento abbia prodotto il report. Non letto: GCOVR_EXCL_FUNCTION — nulla su quella riga dice dove finisce la funzione.

if (handle == NULL) return E_FAIL;   // LCOV_EXCL_BR_LINE: the allocator never fails on target
  // LCOV_EXCL_BR_START generated state table
  switch (state) { /* … */ }
  // LCOV_EXCL_BR_STOP

Screenshot pending — add assets/img/branch-markers.png (see SCREENSHOTS.md).

Dire perché: esclusioni giustificate

Togliere codice dal conteggio è un'affermazione — «questo non si può testare», «questo è un aiuto per lo sviluppatore» — e sotto DO-178C, ISO 26262 o IEC 61508 un'affermazione che cambia il numero su cui poggia un certificato deve essere messa per iscritto e poter essere riesaminata. Perciò un'esclusione può dire perché, nel punto in cui è scritta: il testo dopo LCOV_EXCL_LINE o LCOV_EXCL_START, oppure la Justification di [ExcludeFromCodeCoverage].

abort();                 // LCOV_EXCL_LINE: defensive, unreachable by construction
  // LCOV_EXCL_START debug dump, never built for the target

  [ExcludeFromCodeCoverage(Justification = "a developer aid")]
  public static void DebugDump(decimal amount) { /* … */ }

Le motivazioni vengono lette a ogni caricamento e il log le conta. Export Coverage Report… scrive l'elenco — esclusioni e relative giustificazioni, come Markdown o CSV: il file, le righe, come l'esclusione è stata scritta, e la giustificazione oppure none given. Un file a cui non resta nulla di misurabile è comunque in quell'elenco. Con exclusions.requireReason attivo, un'esclusione che non dà alcuna motivazione è un rilievo: un avviso in Problems alla sua riga, e un fallimento di Check Coverage Thresholds. Exclude Selection from Coverage chiede allora prima la motivazione e la scrive con il marcatore o come Justification dell'attributo; se la richiesta viene chiusa o lasciata vuota, non viene escluso nulla.

Screenshot pending — add assets/img/justified-exclusions.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-justified-exclusions.png (see SCREENSHOTS.md).

12a. Questa copertura descrive ancora questo file?

12b. Non misurato contro non coperto

{
  "fuciniCoverage.unmeasured.mode": "list",
  "fuciniCoverage.threshold.unmeasuredFiles": 0
}

I file di intestazione sono il falso positivo noto in C: hanno la famiglia di estensioni dell'esecuzione e nessun tracefile ne nominerà mai uno, perché da solo non compila in nulla. fuciniCoverage.unmeasured.exclude lascia quindi fuori **/*.h, **/*.hpp, **/*.hh, **/*.inl e **/*.d.ts per impostazione predefinita, nella stessa sintassi glob di fuciniCoverage.ignore; aggiungi un port per una piattaforma che qui non viene compilato, o degli stub generati, ed escono dall'elenco, dal conteggio e dallo stato della barra di stato. Neppure un file nominato da ignore viene mai detto non misurato — lasciarlo fuori era lo scopo. threshold.unmeasuredFiles è predefinito a -1, che non controlla; 0 fallisce nel momento in cui un qualsiasi file del tipo dell'esecuzione non è mai stato caricato da un test, e si applica solo mentre unmeasured.mode è list o count.

13. Report HTML

• Generate Full HTML Report — un report multi-pagina, auto-generato, per directory. L'output va in htmlReport.outputDir, o nell'archivio globale dell'estensione se non impostato.
• Open Annotated Source — una vista annotata per un singolo file. Punta externalHtmlReport.dir a una directory llvm-cov show --format=html pre-costruita per usare quelle pagine invece del renderer integrato.
• Export Fucini JSON — il modello normalizzato completo per i tuoi strumenti.
• Export Coverage Report... — l'esecuzione come CSV (per file o per funzione), riepilogo Markdown, file di trace LCOV, XML Cobertura, SARIF, o badge SVG autonomo per il vostro README. Raggiungibile anche dal pulsante accanto a Generate Full HTML Report nella vista Covered Files. Tutto tranne i CSV perde informazioni — MC/DC, regioni e istanziazioni non trovano posto in LCOV, Cobertura o SARIF — perciò Fucini JSON e i CSV restano i formati che portano ogni metrica.
• Copy Uncovered Lines — un riepilogo Markdown di ogni lacuna, pronto da incollare in una PR.

Screenshot pending — add assets/img/vs-annotated-source.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-directory-summary.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-file-summary.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-coverage-gaps.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-mcdc-detail.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/export-picker.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/annotated-source.png (see SCREENSHOTS.md).

Sorgente annotato rispetto al sorgente semplice

Open Annotated Source sostituisce la scheda attiva con una webview di copertura a colori per quel file, nella stessa colonna; Open Annotated Source to the Side fa lo stesso ma in una vista divisa, così sorgente e vista annotata stanno fianco a fianco. Per passare invece dall'uno all'altro sul posto — utile su schermi piccoli dove una divisione rende ogni riquadro troppo stretto — usa Toggle Annotated Source: scambia la scheda attiva tra le due viste, ricordando quale stai visualizzando. Dall'interno della vista annotata stessa, Show Source torna direttamente all'editor normale per quel file.

L'HTML che vedi effettivamente dipende da externalHtmlReport.dir: se è impostato ed esiste già una pagina corrispondente al file attivo (llvm-cov organizza le pagine per file come <nome-repo>/<percorso-relativo>.html, quindi la cartella con il nome del repository del report non richiede mai configurazione), viene mostrata quella pagina generata dalla toolchain al posto del renderer integrato — i suoi link/foglio di stile locali vengono riscritti per funzionare all'interno della webview, e contiene dettagli che la vista integrata non riproduce (viste di espansione MC/DC, evidenziazione delle regioni, riepiloghi per directory). Nessuna pagina corrispondente per quel file, o impostazione lasciata vuota? Viene allora usato il renderer integrato. L'estensione si limita a leggere questa directory — non vi scrive mai.

Un badge di copertura per il README

Generate Coverage Badge scrive un SVG in stile shields per l'esecuzione attiva nello spazio di lavoro — badge.outputPath, predefinito coverage-badge.svg, relativo alla cartella dello spazio di lavoro o assoluto, con le stesse variabili di ogni altra impostazione di percorso — e propone di aprirlo. È un semplice file nel tuo repository, così un README lo incorpora senza alcun servizio dietro, senza andata e ritorno da shields.io, e funziona anche in un repository isolato dalla rete:

![coverage](coverage-badge.svg)

badge.metric sceglie cosa mostra il badge: lines (etichettato coverage), branches, mcdc o weighted, lo stesso punteggio composito che mostra la barra di stato, etichettato score. Un'esecuzione senza dati per la metrica scelta riceve un n/a grigio anziché uno 0% rosso. Il colore segue i tuoi livelli di colorScale.*: lowColor sotto lowThreshold, midColor fino a highThreshold, highColor da lì in su. Con badge.autoUpdate attivo, il badge viene riscritto dopo ogni caricamento riuscito, in silenzio, e il canale di output registra ogni scrittura come [FUCINI_BADGE] — disattivato per impostazione predefinita perché scrive nello spazio di lavoro a ogni caricamento. Fai il commit dell'SVG insieme al codice e l'immagine sulla pagina del repository segue il numero nell'editor.

{
  "fuciniCoverage.badge.outputPath": "docs/coverage-badge.svg",
  "fuciniCoverage.badge.metric": "weighted",
  "fuciniCoverage.badge.autoUpdate": true
}

14. Cronologia e tendenze

Abilita history.enabled per persistere localmente le esecuzioni (mantenendone history.retention). Otterrai quindi una freccia di tendenza (▲/▼) nella barra di stato, il grafico della tendenza nella vista Coverage e due comandi di confronto: Compare with Last Run e Compare Two History Runs, ciascuno che produce un diff di regressione/miglioramento per file.

Screenshot pending — add assets/img/history-compare.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/since-last-run.png (see SCREENSHOTS.md).

Il grafico della tendenza

Sotto la barra degli strumenti della vista Coverage, con due o più esecuzioni salvate, la coverage di riga della cronologia come una linea, dalla più vecchia alla più recente, le ultime trenta: un punto per esecuzione che al passaggio del mouse dice la sua data e la sua cifra, e l'ultima cifra accanto con una freccia per la direzione dalla prima. La scala verticale è l'intervallo delle esecuzioni stesse, così un team a 92–94% vede il movimento invece di una linea piatta sotto il 100. Entrambe le edizioni lo disegnano dalla stessa cronologia.

Screenshot pending — add assets/img/trend-chart.png (see SCREENSHOTS.md).

Sessioni di coverage

Una sola esecuzione dei test raramente copre tutto ciò che una modifica ha toccato: i test unitari sono girati qui, la suite di integrazione là, un giro nell'interfaccia con la coverage attiva da un'altra parte. Start Coverage Session trasforma i caricamenti che seguono in una sola somma — ogni esecuzione si aggiunge alla precedente riga per riga come unione, una riga che una qualsiasi di esse ha eseguito è coperta e i conteggi si sommano — così il gutter, l'albero e il punteggio mostrano ciò che tutte insieme hanno raggiunto. L'esecuzione sullo schermo, se ce n'è una, è la prima della sessione. Una barra sopra l'albero dice quante esecuzioni da quando e termina la sessione; End Coverage Session fa lo stesso, e il caricamento successivo sta di nuovo da solo. In Visual Studio una sola voce sotto Tools → Coverage Studio avvia la sessione e, spuntata, la termina.

Screenshot pending — add assets/img/coverage-session.gif (see SCREENSHOTS.md).

La baseline CI: dove sono rispetto a main?

Compare with Last Run risponde a cosa ha fatto la vostra ultima modifica; prima di una pull request la domanda è dove state rispetto a main, e la risposta sta sul server di build. baseline.report indica il report che pubblica la build del ramo main, e ogni caricamento viene confrontato con esso: la scheda della barra di stato porta il delta in una riga — vs CI baseline: 84.20% → 85.10% (+0.90%), 3 file(s) moved — e Compare with CI Baseline elenca i file che si sono mossi, file per file, con le stesse parole di Compare with Last Run. In Visual Studio il comando è sotto Tools → Coverage Studio e scarica o legge il report quando lo chiedete. Tre modi per indicarlo, in .vscode/settings.json:

{
  "fuciniCoverage.baseline.report": "https://gitlab.example.com/api/v4/projects/42/jobs/artifacts/main/raw/coverage/lcov.info?job=test",
  "fuciniCoverage.remote.headers": ["PRIVATE-TOKEN: ${env:GITLAB_TOKEN}"]
}

Va bene qualunque formato il lettore conosca. Un percorso che la CI ha scritto relativo al suo checkout — src/Billing/Invoice.cs, come lo scrive Coverlet sul runner — viene collocato sotto questa cartella prima del diff, così incontra il file che l'esecuzione locale ha risolto; un percorso assoluto di un'altra macchina non corrisponde a nulla, quindi fate scrivere alla pipeline percorsi relativi. Una baseline che non si può scaricare o leggere è una riga nel riquadro Output, mai un caricamento fallito.

Screenshot pending — add assets/img/ci-baseline.gif (see SCREENSHOTS.md).

Un artefatto è uno zip, e viene letto anche quello. GitHub e GitLab consegnano un artefatto come archivio, qualunque cosa vi sia stata messa. Indicate il report al suo interno dopo un #: il membro viene trovato dal suo percorso o dalla parte finale di esso; senza # è l'unico file dell'archivio, o il suo unico file che sembra un report, e dove ce ne sono più d'uno il riquadro Output li nomina. Lo stesso vale per uno zip che avete scaricato (ci/artifact.zip#lcov.info) e, in VS Code, per un URL in coverageFile.paths. Il token va al server per cui è stato impostato e non oltre: il reindirizzamento verso lo storage che contiene l'archivio viene seguito senza di esso.

{
  "fuciniCoverage.baseline.report": "https://api.github.com/repos/acme/app/actions/artifacts/1234567/zip#coverage/lcov.info",
  "fuciniCoverage.remote.headers": ["Authorization: Bearer ${env:GITHUB_TOKEN}"]
  }

14a. Per gli agenti IA: la coverage sullo schermo

Un agente che scrive test può eseguirli e leggere una percentuale. Ciò che non può fare da solo è chiedere ciò che l'editor sa: quali righe di questa funzione non sono mai state eseguite, quale lato di quale ramo, quali test raggiungono una riga, se il diff che ha appena scritto è coperto. Sei strumenti rispondono esattamente a questo, con parole su cui un agente può agire, a partire dall'esecuzione caricata — le stesse esclusioni, la stessa rimappatura, gli stessi numeri dello schermo. Così un agente a cui è stato detto di coprire le lacune di una funzione e un revisore che guarda il gutter parlano delle stesse righe.

L'agente di VS Code stesso li ha come strumenti, senza nulla da configurare. Tutti gli altri agenti — qualsiasi client che parli MCP, il Model Context Protocol — vi accedono attraverso un server che l'editor avvia quando mcp.enabled è attivo, in VS Code come in Visual Studio. Copy MCP Server Configuration mette negli appunti la voce del client, così come VS Code e Visual Studio la leggono in un mcp.json; un client che chiama mcpServers la chiave esterna prende la stessa voce sotto quel nome.

Screenshot pending — add assets/img/mcp-config.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-mcp-config.png (see SCREENSHOTS.md).

{
  "servers": {
    "fucini-coverage": {
      "type": "http",
      "url": "http://127.0.0.1:39217/mcp",
      "headers": { "Authorization": "Bearer …" }
    }
  }
  }

• È disattivato finché non lo attivate, e ascolta solo su 127.0.0.1: nulla di esterno a questa macchina lo raggiunge.
• Una chiamata deve portare il vostro token, creato una volta e conservato per voi; senza, la risposta è 401. La configurazione copiata contiene il token: tenetela fuori dal repository.
• Una chiamata inviata da una pagina web — lo dice nel suo Origin — viene rifiutata, qualunque cosa porti.
• Legge l'esecuzione caricata e non scrive nulla. L'esecuzione dei test viene indicata, non avviata: l'agente esegue il comando nel proprio terminale.

La porta è mcp.port, 39217 se non impostata. Dove quella è occupata — una seconda finestra, l'altra edizione accanto a questa — viene usata la prima libera successiva, e la configurazione copiata indica quella che funziona. Il riquadro Output dice dove il server ascolta ([FUCINI_MCP]) e perché non ha potuto ([FUCINI_MCP_001]). Ciò che un piano non include — i nomi dei test, il dettaglio MC/DC — gli strumenti lo contano senza esplicitarlo, come fa l'hover.

15. Riferimento comandi

Screenshot pending — add assets/img/statusbar-and-toolbar.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/statusbar-menu.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/worst-functions.png (see SCREENSHOTS.md).

16. Riferimento impostazioni

La tabella completa e categorizzata delle impostazioni — ogni opzione con il suo valore predefinito — si trova nella pagina Funzionalità e impostazioni. Tutte le chiavi hanno il prefisso fuciniCoverage..

Da notare: fuciniCoverage.language fissa l'interfaccia a runtime di questa estensione (barra di stato, notifiche, suggerimenti, webview) su una lingua specifica, indipendentemente dalla lingua di visualizzazione di VS Code — il valore predefinito è auto e include pacchetti per tutte le 18 lingue supportate. Non modifica le voci della palette dei comandi né le etichette delle impostazioni, che VS Code continua a risolvere dalla propria lingua di visualizzazione.

17. Codici di errore

La diagnostica va nel canale di output Fucini Coverage (View → Output → Fucini Coverage), ciascuna con un codice FUCINI_* stabile.

18. Privacy

La telemetria è controllata dall'impostazione telemetry.enabled con ambito window. È disattivata per impostazione predefinita. Il riepilogo giornaliero e l'avviso di rimozione richiedono inoltre che il telemetry.telemetryLevel globale di VS Code consenta la telemetria; l'avviso di installazione e alcuni piccoli eventi vengono inviati in ogni caso, e così pure la voce nel registro d'uso di un'installazione in prova o sul livello gratuito Community. Su Community, Unlock Full Features scambia questa telemetria con tutte le funzionalità Pro, MC/DC compresa, per 30 giorni, una sola volta per macchina: disattivala di nuovo e vale il set standard di Community; una licenza a pagamento non ne risente in nessun caso. Vedi l'informativa sulla privacy per sapere cosa viene inviato.

Due cose vale la pena conoscere, perché puoi intervenire su di esse. La prima è il tuo ID del registro d'uso: in prova e su Community l'estensione lo mostra in Show License / Activation e in fondo a What Community Includes, dove selezionando la riga lo copi e si apre l'informativa sulla privacy. Il registro conosce la tua macchina tramite un hash e nient'altro, quindi quell'ID è l'unico modo per chiedere che cosa contiene sul tuo conto, farlo cancellare oppure opporti — indicacelo e troveremo la tua riga; senza di esso non possiamo. La seconda è la registrazione di installazione: una riga scritta la prima volta che un'installazione si segnala e conservata anziché cancellata dopo 90 giorni, con l'identificatore di installazione, il giorno, il luogo a cui è stato risolto il suo indirizzo, le versioni e il sistema operativo — non l'indirizzo stesso, e nulla sul tuo codice. È ciò che ci permette di dire quante installazioni ci sono state negli anni. Entrambe le cose sono descritte per esteso nell'informativa sulla privacy, ed entrambe vengono cancellate se lo chiedi.

19. Valutazione e attivazione

Fucini Coverage Studio è distribuito come anteprima di valutazione. Al primo avvio ti viene chiesto di accettare di valutarlo e la prova inizia: tutte le funzionalità sono disponibili durante una prova di 14 giorni, contati dal primo utilizzo su quell'installazione. Non c'è una data fissa dopo la quale qualcosa smette di funzionare.

Dalla versione 2.2026.2 la prova di una nuova installazione inizia non appena l’estensione ha raggiunto una volta il server delle licenze; fino ad allora funziona al livello Community e lo dice. In un container di sviluppo o in un Codespace non inizia alcuna prova: un codice di abbonamento, una chiave o il pass di 7 giorni sblocca lì l’insieme completo.

Alla fine della prova non viene bloccato nulla: l'estensione passa al livello gratuito Community. Per riavere il set completo, attiva: l'attivazione si collega al server delle licenze e applica automaticamente la chiave restituita, senza e-mail e senza chiavi da copiare a mano:

Screenshot pending — add assets/img/licence-dialog.png (see SCREENSHOTS.md).

1. Esegui Fucini Coverage: Show License / Activation (raggiungibile anche dalla barra di stato una volta scaduta la prova o la chiave) e fai clic su Request License… (oppure Request Renewed Key… se hai già attivato).
2. Conferma la richiesta. La chiave viene emessa automaticamente e i tuoi dati di contatto di una richiesta precedente vengono riutilizzati anziché richiesti di nuovo.
3. Fatto. La chiave di attivazione viene generata e scritta automaticamente in fuciniCoverage.license.key. La barra di stato passa dalla prova a una licenza attivata in un attimo.

La via manuale in un’immagine: apri il pannello della licenza, scegli Enter Key, incolla la chiave ricevuta per e-mail e il banner passa a «Activated».

Screenshot pending — add assets/img/activate-key.gif (see SCREENSHOTS.md).

{ "fuciniCoverage.license.key": "FCK1.…incolla qui l'intera chiave…" }

Il livello gratuito Community: una quota settimanale

Community non smette mai di mostrare la copertura. I margini, il righello di panoramica, i suggerimenti al passaggio del mouse, CodeLens, la vista Coverage, la modalità watch, la copertura del diff e la cronologia non vengono conteggiati affatto, e il caricamento di un tracefile tramite comando ha come unico limite 25 al giorno. Ciò che viene misurato è l'output: cinque alla settimana ciascuno per l'apertura del report HTML, l'esportazione, il confronto tra due esecuzioni, la verifica delle soglie e la visualizzazione del sorgente annotato in loco.

La settimana è tua, non del calendario: inizia con il primo utilizzo e finisce sette giorni dopo. Quando una quota è esaurita, il messaggio indica l'azione e il giorno in cui torna disponibile, e dopo quell'unico messaggio ne parla soltanto la barra di stato. Fucini Coverage: What Community Includes elenca ogni quota con quanto è stato usato e quando si azzera, prima ancora che tu ne raggiunga una.

Screenshot pending — add assets/img/weekly-allowance.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/community-limit-prompt.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/community-includes-weekly.png (see SCREENSHOTS.md).

Tre dettagli appartengono ai piani a pagamento, mentre i relativi risultati restano gratuiti: Community contrassegna ogni riga che ha mutanti sopravvissuti e dice quanti sono, ma non che cosa ha modificato ciascun mutante; dice quanti test hanno eseguito una riga, ma non i loro nomi; e mostra il Max CRAP di un'esecuzione, ma non l'elenco in classifica Riskiest Methods.

Screenshot pending — add assets/img/mutant-hover-community.png (see SCREENSHOTS.md).

Se usavi già Community quando è arrivata la quota settimanale (0.2026.83), i tuoi limiti precedenti restano validi per 30 giorni; ti viene comunicato una sola volta, con la data. I contatori sono conservati sul tuo computer — nell'archivio proprio di VS Code e in ~/.fucini-coverage/, così un nuovo profilo VS Code prosegue la stessa settimana — e non vengono mai inviati da nessuna parte.

Il pass di 7 giorni

Non sei pronto per un abbonamento? Un pass di 7 giorni è tutto ciò che offre Pro per una settimana, pagato una volta sola: nessun rinnovo e niente da disdire. Acquistalo nella pagina dei prezzi (il messaggio mostrato a un limite di Community ha un pulsante apposito) e il codice di attivazione arriva via email.

Screenshot pending — add assets/img/pricing-week-pass.png (see SCREENSHOTS.md).

1. Esegui Fucini Coverage: Enter Subscription Code — esiste sia nell'edizione Community sia in Pro.
2. Scegli Pro e incolla il codice FCB1-… ricevuto via email.
3. Tutto qui. La chiave viene emessa e applicata per te, e funziona offline. La settimana decorre dal pagamento, quindi attiva il pass quando lo acquisti. Al termine, l'estensione torna da sola a Community e continua a mostrare la copertura.

Screenshot pending — add assets/img/pass-step-plan.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/pass-step-code.png (see SCREENSHOTS.md).

Passare a un nuovo computer e gestire i posti

Una chiave è legata a una macchina, quindi un computer nuovo ne richiede una nuova — e il tuo abbonamento paga solo le macchine che dichiara. Libera tu stesso quella vecchia: accedi a gestisci il tuo abbonamento, individua il posto che non usi più, scegli Free up e attiva la nuova macchina con lo stesso codice. Lʼacquisto di Pro non ti invia alcuna password: il tuo account esiste, semplicemente non ne ha ancora una, quindi la prima volta usa imposta o reimposta la password con lʼindirizzo con cui ti sei abbonato.

Su Business ed Enterprise inviti ogni collega via e-mail dalla stessa pagina. Ognuno riceve un codice di attivazione solo suo e, appena lo usa, il suo indirizzo compare accanto al suo posto: quando qualcuno se ne va vedi qual era il suo e lo liberi per il prossimo. Un invito occupa un posto dal momento in cui lo mandi e scade dopo 14 giorni se resta inutilizzato; ritiralo per riavere subito il posto.

Provare le versioni preliminari

Le novità arrivano su fucini.software prima che sul Marketplace, e puoi chiedere che ti vengano proposte. Apri la vista Coverage, espandi il pannello della licenza e premi Prova le versioni preliminari… — oppure imposta fuciniCoverage.update.preRelease. Da quel momento l'estensione controlla qui un feed preliminare separato oltre a quello ordinario, e propone la più recente delle due.

Screenshot pending — add assets/img/licence-prerelease.png (see SCREENSHOTS.md).

Le versioni preliminari sono testate, ma sono le build di cui siamo meno sicuri: ti offriresti volontario per trovare ciò che ci è sfuggito. Unendoti ci dici che questa installazione è sul canale, così sappiamo quante persone stanno provando e possiamo dirti cosa è cambiato; uscendo, la prossima versione stabile ti riporta sul percorso abituale. Non c'è sempre una versione preliminare disponibile, e unirsi quando non ce n'è non costa nulla: l'estensione trova un feed vuoto, non ne dice niente e continua a proporre versioni stabili finché non ne viene pubblicata una.

Screenshot pending — add assets/img/licence-prerelease-joined.png (see SCREENSHOTS.md).

20. Contatti e licenza

Domande, segnalazioni di bug o termini di licenza alternativi — vedi la pagina contatti o scrivi a info@fucini.consulting. Concesso in licenza secondo MIT con una condizione di attribuzione nelle note di rilascio; vedi anche Notice.

21. Sulla riga di comando

Il lettore gira anche senza un editor: npm install -g fucini-coverage, gratis, su Windows, Linux, WSL e macOS. fucini-coverage check coverage/lcov.info --lines 80 è il gate su cui una pipeline fallisce; summary, export, report, badge e compare fanno ciò che fanno i comandi degli editor con quei nomi, e mcp serve i sei strumenti della sezione qui sopra a un agente su un server. Legge fucini-coverage.json, il file delle impostazioni che legge l'edizione per Visual Studio, così le soglie si impostano una volta sola. fucini-coverage help <command> spiega ciascuno; la pagina completa è fucini-coverage su npm.

Screenshot pending — add assets/img/cli-demo.gif (see SCREENSHOTS.md).