Registro modifiche

Corretto

• La cartella da cui si avvia il comando non decide che cosa significhi un report. 2.2026.3 ancora i percorsi relativi di un report alla cartella in cui quel report è stato scritto, ma solo per un comando avviato altrove. Eseguito dalla radice dell’albero che misura — cioè dove un comando di copertura si esegue di solito — un percorso relativo veniva ancora risolto su quella cartella, e un file che llvm-cov aveva già nominato per intero veniva contato una seconda volta: un albero di 5.258 righe si leggeva 5.836. Ora decidono soltanto --cwd e la posizione del report stesso. La stessa correzione è nei due editor, dove la cartella era quella da cui VS Code o Visual Studio era stato avviato.
• export --format json scriveva la run sopra le tue impostazioni. Il suo file era fucini-coverage.json — il nome da cui le impostazioni vengono lette — così in una cartella configurata nel modo consueto l’esportazione distruggeva le soglie con cui aveva appena giudicato. La run viene scritta in coverage-run.json, e export e badge rifiutano un --out che nomini il file delle impostazioni.
• --cwd prende una cartella comunque la si scriva. Una relativa — --cwd ., --cwd ../tree — veniva presa com’era scritta e letta con le regole di percorso sbagliate: su Windows rispondeva che un file di impostazioni metà POSIX e metà Windows non si poteva leggere, e non trovava alcun report. Nemmeno un separatore finale fa più parte della cartella.
• Un’opzione che nessuno ha dichiarato non è un report. summary -o out.json prendeva -o per un report e diceva che quel file non esiste. Solo -h e -v sono brevi; -- passa ancora un file il cui nome comincia con un trattino, e un’opzione scritta prima del comando viene nominata nell’errore invece di ricevere in risposta tutta la guida.
• check --json dice quello che dice il suo codice di uscita. Senza alcuna soglia impostata scriveva "passed": false accanto al codice di uscita 0, e una pipeline che leggeva il JSON invece del codice di uscita faceva fallire una run che il comando aveva superato. passed è il codice di uscita in una parola; configured è ciò che dice che non c’era alcun cancello. Un --lines "" vuoto viene rifiutato invece di spegnere quel cancello in silenzio.
• Un confronto mette la baseline dove mette la run. pathRemap e la radice dichiarata da un report venivano applicati alla run e non alla baseline, così una baseline scritta su un server di build non si accoppiava con nulla e il confronto riferiva che non si era mosso niente accanto a un totale che si era chiaramente mosso.

Corretto

• I percorsi relativi di un report sono ancorati alla cartella in cui quel report è stato scritto. llvm-cov scrive il percorso completo di un file; gcovr lo scrive relativo alla cartella di build in cui si trova il suo report. Con entrambi i report di un albero, summary elencava due volte ogni file che i due avevano in comune — una volta con i numeri di ciascun motore — e sommava entrambi al totale, perché un percorso relativo non aveva una radice su cui risolversi e si risolveva sulla cartella in cui si trovava la shell in quel momento. Un albero di 5.258 righe veniva riportato come 5.836, e l’eccesso apparteneva a file sotto un percorso che non ne contiene nessuno. Ora ogni report è ancorato alla propria cartella e a quelle superiori, fino alla cartella in cui gira il comando, come già fanno entrambe le edizioni: così i due si incontrano come un unico insieme di file, senza una regola pathRemap per ogni directory di build.
• Anche un file di impostazioni che inizia con un byte order mark veniva rifiutato. Un editor su Windows può scriverlo davanti al testo; non viene più preso per parte del JSON.
• L’output inviato in pipe a un lettore che si ferma presto termina in silenzio. summary in pipe verso head, o verso il Select-Object -First di PowerShell, moriva con un EPIPE non gestito e uno stack trace. Che il lettore chiuda la pipe è una sua scelta, non un errore del comando: ora termina con il codice di uscita che aveva raggiunto.

Corretto

• Un file di impostazioni con pattern veniva rifiutato. Con **/*.lcov.info in un percorso di fuciniCoverage.coverageFile.paths e **/coverage.json nel successivo, ogni comando terminava con is not JSON: ciò che stava tra i due veniva scambiato per un commento. Ora il file viene letto come lo leggono gli editor, compresi un commento dopo un valore e una virgola prima di una parentesi di chiusura.

Aggiunto

• Il lettore sulla riga di comando, gratis. npm install -g fucini-coverage — lo stesso lettore delle due edizioni, per i posti dove un editor non c'è. Un pacchetto, un comportamento su Windows, Linux, WSL e macOS, Node 20 o più recente.
• check, il gate. Codice di uscita 1 sotto una soglia su righe, rami, funzioni, MC/DC, condizioni, regioni, mutazione o punteggio pesato, dalle impostazioni o dalla riga di comando; --new-code 80 --base-ref origin/main giudica le righe che un ramo ha cambiato, da un git diff eseguito dallo strumento; --require-reasons boccia un marcatore di esclusione senza motivo.
• summary, export, report, badge, compare. I totali e ogni file; l'esecuzione come CSV per file o per funzione, Markdown, LCOV, Cobertura, SARIF, l'elenco delle esclusioni, un badge o il JSON di Fucini; il report HTML multipagina; il badge colorato secondo la scala delle impostazioni; questa esecuzione rispetto a una baseline, regressioni per prime, con --fail-on-regression per un controllo sulla pull request.
• mcp, per un agente IA. I sei strumenti delle edizioni, serviti sull'esecuzione su 127.0.0.1 dietro un token, con la voce per l'mcp.json del client stampata.
• Il file delle impostazioni dell'edizione per Visual Studio. fucini-coverage.json accanto al codice, con le chiavi fuciniCoverage.* delle impostazioni di VS Code; sotto di esso .vscode/settings.json. I report si indicano come file, cartelle o pattern, un .gz viene decompresso, e ogni comando si documenta da sé: fucini-coverage help <command>.

Modificato

• La prova di una nuova installazione inizia con la prima risposta del server delle licenze. Finché l’estensione non ha raggiunto fucini.software una volta, funziona al livello Community e dice perché. Un’installazione già in prova, o con una licenza, non nota nulla.
• Nessuna prova in un container di sviluppo o in un Codespace. Lì l’estensione parte al livello Community; un codice di abbonamento, una chiave o il pass di 7 giorni sblocca tutto.
• Il registro d’uso conosce una macchina da un secondo hash, quello dell’identificativo proprio del sistema operativo. Viene inviato solo l’hash; vedi l’informativa sulla privacy.

Corretto

• Piccole correzioni. Una release di manutenzione: piccole correzioni sotto il cofano, e nulla che cambi ciò che vedi o come lo usi.

Corretto

• Piccole correzioni. Una release di manutenzione: piccole correzioni sotto il cofano, e nulla che cambi ciò che vedi o come lo usi.

Aggiunto

• La copertura a schermo, per gli agenti IA. Un agente che scrive test poteva eseguirli e leggere una percentuale; non poteva chiedere ciò che Visual Studio sa. Sei strumenti rispondono a questo, in parole su cui un agente può agire: coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta e test_run_command. Un agente che parla MCP li raggiunge tramite un server che Visual Studio esegue quando fuciniCoverage.mcp.enabled è attivo — disattivato per impostazione predefinita, solo su 127.0.0.1, dietro un token tutto vostro, e chiuso alle pagine web. Copy MCP Server Configuration mette negli appunti la voce per il client.
• Gli stessi numeri che a schermo. Gli strumenti rispondono dall’esecuzione caricata — le stesse esclusioni, la stessa rimappatura — così un agente a cui si chiede di coprire le lacune di una funzione e un revisore che guarda il margine parlano delle stesse righe.

Modificato

• Il piano di una chiave decide in Visual Studio ciò che decide in VS Code. Un piano che lascia fuori una funzionalità — MC/DC, il report HTML, i nomi dei test che hanno eseguito una riga — la lasciava fuori in VS Code e non qui. Entrambe le edizioni leggono ora la stessa tabella: una funzionalità che il piano non include viene negata, e il suo comando lo dice.
• La versione minima richiesta dal server delle licenze vale anche qui. Entrambe le edizioni portano la stessa versione dalla 2.2026.0 in poi, quindi una build più vecchia di quel minimo chiede di essere aggiornata, come fa l’edizione per VS Code.

Aggiunto

• La copertura a schermo, per gli agenti IA. Un agente che scrive test poteva eseguirli e leggere una percentuale; non poteva chiedere ciò che l’editor sa. Sei strumenti rispondono a questo, in parole su cui un agente può agire: coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta e test_run_command. L’agente proprio di VS Code li ha come strumenti del modello linguistico, senza nulla da configurare. Ogni altro agente che parla MCP li raggiunge tramite un server che l’estensione esegue quando fuciniCoverage.mcp.enabled è attivo — disattivato per impostazione predefinita, solo su 127.0.0.1, dietro un token tutto vostro, e chiuso alle pagine web. Copy MCP Server Configuration mette negli appunti la voce per il client.
• Gli stessi numeri che a schermo. Gli strumenti rispondono dall’esecuzione caricata — le stesse esclusioni, la stessa rimappatura — così un agente a cui si chiede di coprire le lacune di una funzione e un revisore che guarda il margine parlano delle stesse righe.

Corretto

• Un file misurato da due motori è un solo file. llvm-cov scrive il percorso completo di un file; gcovr lo scrive relativo alla cartella di build in cui si trova il suo report. Un percorso relativo viene ancorato alla cartella del report stesso e a quelle sopra di essa — ma prima di ciò il risolutore chiedeva se il percorso esistesse così com’era, e a quella domanda risponde la cartella da cui è stato avviato Visual Studio stesso. Se quella cartella conteneva il file, il percorso restava relativo: il file aveva due nomi, compariva due volte nella finestra Coverage e contava due volte nei totali. Un albero di 5.258 righe si leggeva 5.836. Un percorso che non nomina alcuna posizione propria non viene più chiesto affatto; viene ancorato dove il report è stato scritto, e la riga lo dice.

Corretto

• Un file misurato da due motori è un solo file. llvm-cov scrive il percorso completo di un file; gcovr lo scrive relativo alla cartella di build in cui si trova il suo report. Un percorso relativo viene ancorato alla cartella del report stesso e a quelle sopra di essa — ma prima di ciò il risolutore chiedeva se il percorso esistesse così com’era, e a quella domanda risponde la cartella da cui è stato avviato l’extension host, che dopo code . è la radice del tuo progetto. Il percorso restava allora relativo: il file aveva due nomi, compariva due volte nella vista Coverage e contava due volte nei totali. Un albero di 5.258 righe si leggeva 5.836. Un percorso che non nomina alcuna posizione propria non viene più chiesto affatto; viene ancorato dove il report è stato scritto, e la riga lo dice.
• La modalità del margine che scegli vale per la sessione, e le tue impostazioni restano come le hai scritte. Scegliere una modalità dalla barra di stato, dal selettore o con Toggle Coverage Painting la scriveva in settings.json — un file che in molti progetti è sotto controllo di versione, riscritto da un pulsante fatto per essere premuto due volte al minuto. La scelta ora vive per la sessione, e una modalità che hai scritto nelle tue impostazioni vince ancora all’apertura della finestra.

Aggiunto

• Run Mutation Tests Here. La copertura dice che una riga è stata eseguita; uno strumento di mutazione dice se un test si accorgerebbe che è sbagliata. La funzione in cui si trova il cursore — o le righe selezionate, o il file — è ciò che allo strumento di mutazione della cartella viene detto di mutare, e il suo report viene caricato accanto alla copertura a schermo: Stryker.NET per C#, StrykerJS per JavaScript e TypeScript, PIT con Maven per Java. L’esecuzione di mutazione di un progetto richiede un’ora; quella di una funzione, un minuto.

Aggiunto

• Run Mutation Tests Here. La copertura dice che una riga è stata eseguita; uno strumento di mutazione dice se un test si accorgerebbe che è sbagliata. La funzione in cui si trova il cursore — o le righe selezionate, o il file — è ciò che allo strumento di mutazione della cartella viene detto di mutare, e il suo report viene caricato accanto alla copertura a schermo: Stryker.NET per C#, StrykerJS per JavaScript e TypeScript, PIT con Maven per Java. L’esecuzione di mutazione di un progetto richiede un’ora; quella di una funzione, un minuto.

Aggiunto

• Run App with Coverage… misura ciò che una persona raggiunge, non solo ciò che fanno i test: l’app .NET della cartella viene avviata sotto dotnet-coverage di Microsoft, in una console tutta sua, e gira finché non viene chiusa. Ciò che è stato percorso viene poi caricato come qualsiasi esecuzione, e in una sessione di copertura sommato a ciò che i test hanno eseguito. Richiede dotnet tool install --global dotnet-coverage.

Aggiunto

• Run App with Coverage… misura ciò che una persona raggiunge, non solo ciò che fanno i test: l’app .NET della cartella viene avviata sotto dotnet-coverage di Microsoft, in una console tutta sua, e gira finché non viene chiusa. Ciò che è stato percorso viene poi caricato come qualsiasi esecuzione, e in una sessione di copertura sommato a ciò che i test hanno eseguito. Richiede dotnet tool install --global dotnet-coverage.

Aggiunto

• Una baseline CI da un artifact zip. GitHub e GitLab pubblicano un artifact come archivio. Dove baseline.report ne indica uno — un URL, o uno zip su disco — viene aperto e il report al suo interno conservato: il membro indicato dopo il # (ci/artifact.zip#coverage/lcov.info), altrimenti l’unico file dell’archivio, altrimenti il suo unico file che sembra un report.

Aggiunto

• Artifact zip da GitHub e GitLab. La CI pubblica un artifact, e un artifact è un archivio. Uno zip scaricato ora viene aperto e il report al suo interno conservato — il membro indicato dopo il # dell’URL (…/zip#coverage/lcov.info), altrimenti l’unico file dell’archivio, altrimenti il suo unico file che sembra un report. Per un URL in coverageFile.paths, per baseline.report, e per una baseline che è uno zip su disco.

Corretto

• I file di una baseline Cobertura non venivano trovati sotto il <source> del report stesso. Il confronto diceva 0 file(s) moved accanto a un totale che si era mosso. Ora si usa la radice indicata dal report, come per un report che viene caricato.

Aggiunto

• Codice nuovo per autore e per data. Il codice nuovo erano le righe modificate rispetto a un ref git. Due impostazioni chiedono ciò che un ref non può dire: fuciniCoverage.gitDiff.author — le righe scritte da una persona — e fuciniCoverage.gitDiff.since — le righe scritte a partire da un giorno. Entrambe vengono lette da git blame e si applicano alla copertura del diff e alla soglia sul codice nuovo.

Aggiunto

• Codice nuovo per autore e per data. Il codice nuovo erano le righe modificate rispetto a un ref git. Due impostazioni chiedono ciò che un ref non può dire: fuciniCoverage.gitDiff.author — le righe scritte da una persona — e fuciniCoverage.gitDiff.since — le righe scritte a partire da un giorno. Entrambe vengono lette da git blame e si applicano alla copertura del diff e alla soglia sul codice nuovo.

Aggiunto

• Run This Test with Coverage legge Go e Rust. In un file Go il func TestXxx del cursore viene eseguito da solo, nel proprio package e con il suo nome esatto — go test ./pkg/calc -run "^TestTotal$". In un file Rust la funzione #[test] viene eseguita con il suo percorso nel crate, --exact; in un mod, i test di quel modulo; un test di integrazione sotto tests/, nel proprio binario.

Aggiunto

• Run This Test with Coverage legge Go e Rust. In un file Go il func TestXxx del cursore viene eseguito da solo, nel proprio package e con il suo nome esatto — go test ./pkg/calc -run "^TestTotal$". In un file Rust la funzione #[test] viene eseguita con il suo percorso nel crate, --exact; in un mod, i test di quel modulo; un test di integrazione sotto tests/, nel proprio binario.

Aggiunto

• La copertura delle condizioni di GCC 14, riga per riga. -fcondition-coverage veniva letto come due conteggi per file; ora ogni condizione è segnata sulla sua riga e nominata nel tooltip — condizione 1 mai vera, condizione 0 mai in nessuno dei due sensi — dal JSON di gcov e dal suo listato testuale. threshold.conditions ne fa una soglia, Copy Coverage Summary ha una colonna Conditions, badge.metric accetta conditions, e la ricerca accetta conditions < 80.

Corretto

• Il valore dei branch di una funzione contava anche gli esiti delle sue condizioni. branches 8/12 dove lo strumento diceva 4 su 6. Le condizioni ne restano fuori, come nei valori del file e dell’esecuzione.

Aggiunto

• La copertura delle condizioni di GCC 14, riga per riga. -fcondition-coverage veniva letto come due conteggi per file; ora ogni condizione è segnata sulla sua riga e nominata nel tooltip — condizione 1 mai vera, condizione 0 mai in nessuno dei due sensi — dal JSON di gcov e dal suo listato testuale. threshold.conditions ne fa una soglia, Copy Coverage Summary ha una colonna Conditions, badge.metric accetta conditions, e la ricerca accetta conditions < 80.

Corretto

• Il valore dei branch di una funzione contava anche gli esiti delle sue condizioni. branches 8/12 dove lo strumento diceva 4 su 6. Le condizioni ne restano fuori, come nei valori del file e dell’esecuzione.

Aggiunto

• La vista Coverage segue l’editor. Il file che state guardando viene evidenziato nell’albero, le cartelle sopra di esso vengono aperte e la sua riga viene portata in vista. fuciniCoverage.coverageView.followActiveEditor lo disattiva.

Aggiunto

• La vista Coverage segue l’editor. Il file che state guardando viene evidenziato nell’albero, le cartelle sopra di esso vengono aperte e la sua riga viene portata in vista. fuciniCoverage.coverageView.followActiveEditor lo disattiva.

Aggiunto

• Marcatori di esclusione per i soli branch e di gcovr. LCOV_EXCL_BR_LINE e LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP tolgono dal conteggio i branch sulle loro righe e vi lasciano le righe; LCOV_EXCL_EXCEPTION_BR_LINE toglie solo i rami raggiunti da un’eccezione. Ogni marcatore viene letto anche con i prefissi di gcovr: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE e gli altri.

Corretto

• Un report .NET non mostrava alcuna copertura dei branch. Coverlet e dotnet-coverage scrivono l’attributo branch di una riga Cobertura come True, e veniva letto solo il true minuscolo — così ogni decisione in un report del genere andava persa. Ora vengono lette entrambe le grafie. I numeri si muovono: la copertura dei branch di un progetto .NET compare dove non ce n’era, e con essa il suo punteggio.
• Un report Cobertura unito da più alberi trovava solo i file del primo albero. Un report del genere indica un <source> per albero; ora viene provato ciascuno, nell’ordine del report.

Aggiunto

• Marcatori di esclusione per i soli branch e di gcovr. LCOV_EXCL_BR_LINE e LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP tolgono dal conteggio i branch sulle loro righe e vi lasciano le righe; LCOV_EXCL_EXCEPTION_BR_LINE toglie solo i rami raggiunti da un’eccezione. Ogni marcatore viene letto anche con i prefissi di gcovr: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE e gli altri.

Corretto

• Un report .NET non mostrava alcuna copertura dei branch. Coverlet e dotnet-coverage scrivono l’attributo branch di una riga Cobertura come True, e veniva letto solo il true minuscolo — così ogni decisione in un report del genere andava persa. Ora vengono lette entrambe le grafie. I numeri si muovono: la copertura dei branch di un progetto .NET compare dove non ce n’era, e con essa il suo punteggio.
• Un report Cobertura unito da più alberi trovava solo i file del primo albero. Un report del genere indica un <source> per albero; ora viene provato ciascuno, nell’ordine del report.

Aggiunto

• Show Minimal Test Set… trova il minor numero di test che esegue ancora ogni riga eseguita dalla suite, ed elenca sotto di essi i test che non aggiungono alcuna riga propria. Per l’esecuzione veloce prima di un commit, e per chi sfoltisce la suite — con il promemoria che ridondante per righe non significa ridondante per ciò che un test verifica.

Aggiunto

• Show Minimal Test Set… trova il minor numero di test che esegue ancora ogni riga eseguita dalla suite, ed elenca sotto di essi i test che non aggiungono alcuna riga propria. Per l’esecuzione veloce prima di un commit, e per chi sfoltisce la suite — con il promemoria che ridondante per righe non significa ridondante per ciò che un test verifica.

Aggiunto

• Esclusioni giustificate. Il codice tolto dal conteggio là dove è scritto può dire perché — // LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] — e le ragioni vengono riportate: Export Coverage Report… elenca le esclusioni e le loro giustificazioni in Markdown e in CSV. Con fuciniCoverage.exclusions.requireReason un’esclusione che non dà alcuna ragione è un avviso sulla sua riga e fa fallire Check Coverage Thresholds.

Aggiunto

• Esclusioni giustificate. Il codice tolto dal conteggio là dove è scritto può dire perché — // LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] — e le ragioni vengono riportate: Export Coverage Report… elenca le esclusioni e le loro giustificazioni in Markdown e in CSV. Con fuciniCoverage.exclusions.requireReason un’esclusione che non dà alcuna ragione è un avviso sulla sua riga e fa fallire Check Coverage Thresholds.

Aggiunto

• Una soglia sul codice nuovo, accanto alle soglie sull’intera esecuzione. fuciniCoverage.threshold.newCode è la copertura minima delle righe, in percentuale, delle righe modificate rispetto a gitDiff.baseRef. Check Coverage Thresholds la dà per fallita in una frase a sé — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) — e l’intera esecuzione resta a schermo.
• Show Indirect Coverage Changes… elenca le righe la cui copertura si è mossa anche se nessuno le ha modificate — codice che ha smesso di essere eseguito perché un test è sparito, o perché un branch a monte ora ritorna prima. Rispetto alla baseline CI dove baseline.report ne indica una, altrimenti rispetto all’esecuzione precedente.

Aggiunto

• Una soglia sul codice nuovo, accanto alle soglie sull’intera esecuzione. fuciniCoverage.threshold.newCode è la copertura minima delle righe, in percentuale, delle righe modificate rispetto a gitDiff.baseRef. Check Coverage Thresholds la dà per fallita in una frase a sé — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) — e l’intera esecuzione resta a schermo.
• Show Indirect Coverage Changes… elenca le righe la cui copertura si è mossa anche se nessuno le ha modificate — codice che ha smesso di essere eseguito perché un test è sparito, o perché un branch a monte ora ritorna prima. Rispetto alla baseline CI dove baseline.report ne indica una, altrimenti rispetto all’esecuzione precedente.

Aggiunto

• Run Tests Affected by My Changes… elenca i test che hanno eseguito una riga che l’albero di lavoro modifica rispetto a fuciniCoverage.testImpact.baseRef (HEAD per impostazione predefinita), 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.

Corretto

• testRun.skipWhenTestsFail vale anche dopo l’esecuzione. I report scritti da un’esecuzione rossa restavano su disco, dove il watcher li caricava un attimo dopo. Ora vengono rimossi.
• La copia che un logger TRX fa di un report di copertura non viene mai presa per un tracefile.

Aggiunto

• Run Tests Affected by My Changes… elenca i test che hanno eseguito una riga che l’albero di lavoro modifica rispetto a fuciniCoverage.testImpact.baseRef (HEAD per impostazione predefinita), 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.

Corretto

• testRun.skipWhenTestsFail vale anche dopo l’esecuzione. I report scritti da un’esecuzione rossa restavano su disco, dove il watcher li caricava un attimo dopo. Ora vengono rimossi.
• La copia che un logger TRX fa di un report di copertura non viene mai presa per un tracefile.

Aggiunto

• Superato o fallito sui segni. Una riga eseguita da un test fallito riceve una barra rossa all’inizio, e il suo tooltip nomina i test falliti; Show Tests That Ran This Line dice quali dei test sono falliti. Serve un report che dica quali test hanno eseguito una riga, e il file dei risultati del test runner — TRX o JUnit XML — nella cartella del report o indicato in fuciniCoverage.testResults.paths. Run Tests with Coverage ora ne chiede uno a dotnet test.
• La copertura del codice di Visual Studio stesso, caricata. Il file .coverage che Analyze Code Coverage di Visual Studio scrive viene convertito con dotnet-coverage e caricato da solo: Coverage Studio si appoggia al collector integrato invece di fargli concorrenza.

Aggiunto

• Superato o fallito sui segni. Una riga eseguita da un test fallito riceve una barra rossa all’inizio, e il suo tooltip nomina i test falliti; Show Tests That Ran This Line dice quali dei test sono falliti. Serve un report che dica quali test hanno eseguito una riga, e il file dei risultati del test runner — TRX o JUnit XML — nella cartella del report o indicato in fuciniCoverage.testResults.paths. Run Tests with Coverage ora ne chiede uno a dotnet test.

Corretto

• La casella di ricerca conserva la query, e il focus, quando la copertura si ricarica. Ogni ricaricamento la svuotava, spesso mentre la query era ancora in fase di digitazione. Una query come < 80% conserva anche gli hotspot di rischio a cui corrisponde.
• Una sessione di copertura non conta più due volte la stessa esecuzione. Ogni ricaricamento di report invariati li sommava di nuovo, e ogni conteggio di esecuzioni raddoppiava. Una sessione ora conserva ogni insieme di report una volta sola.
• La baseline CI non trattiene più un caricamento. Prima viene disegnato il caricamento, poi segue il confronto. La baseline viene preparata una volta e conservata finché il suo report e le impostazioni restano gli stessi, e quando l’URL non è raggiungibile si usa la copia scaricata in precedenza.
• «Dall’ultima esecuzione» sopravvive a un ricaricamento di report invariati. Una modifica delle impostazioni o un aggiornamento faceva dell’esecuzione a schermo la propria ultima esecuzione, e ogni cambiamento rispetto all’esecuzione precedente spariva. Una rilettura del genere non viene più nemmeno conservata nella cronologia.
• Un caricamento alla volta. Due ricaricamenti richiesti insieme giravano fianco a fianco, e vinceva il più lento. I ricaricamenti richiesti durante un caricamento diventano ora un unico caricamento dopo di esso.
• Una baseline CI via HTTP viene scaricata come in VS Code. Un solo client, l’ultima copia conservata per quando il server non è raggiungibile, e remote.headers inviati solo all’indirizzo per cui sono stati scritti — mai su HTTP in chiaro.
• Un comando il cui lavoro fallisce lo dice. Un errore in un comando o in un timer veniva inghiottito; ora è una riga nella finestra Output.
• Meno lavoro sul thread dell’interfaccia utente. I watcher dei file vengono creati in background, le voci dell’Elenco errori vengono calcolate una volta per caricamento, e il log viene scritto a raffiche anziché riga per riga.
• Due finestre di Visual Studio non danneggiano più la cronologia delle esecuzioni. Il suo indice viene sostituito in un solo passaggio sotto un lock condiviso da entrambe, e ricostruito dalle esecuzioni quando va perso.
• Run Native Project with Coverage compila la piattaforma propria del progetto, e prende llvm-cov e llvm-profdata dall’LLVM del compilatore, in coppia.
• I colori di avviso, errore e superato della finestra Coverage seguono un tema chiaro come uno scuro.
• Un file delle impostazioni aperto con modifiche non salvate non viene sovrascritto. La pagina delle impostazioni dice di salvarlo prima.

Modificato

• Un file di copertura che scegliete, e il report che un’esecuzione di test scrive, vengono ricordati per voi invece di essere scritti in .vscode/settings.json. Quel file è spesso sotto commit, quindi un’esecuzione di test lasciava nel repository una modifica che nessuno aveva chiesto. I percorsi già presenti in coverageFile.paths continuano a funzionare.

Corretto

• La casella di ricerca conserva la query, e il focus, quando la copertura si ricarica. Ogni ricaricamento la svuotava, spesso mentre la query era ancora in fase di digitazione. Una query come < 80% conserva anche gli hotspot di rischio a cui corrisponde.
• Una sessione di copertura non conta più due volte la stessa esecuzione. Ogni ricaricamento di report invariati li sommava di nuovo, e ogni conteggio di esecuzioni raddoppiava. Una sessione ora conserva ogni insieme di report una volta sola.
• La baseline CI non trattiene più un caricamento. Prima viene disegnato il caricamento, poi segue il confronto. La baseline viene preparata una volta e conservata finché il suo report e le impostazioni restano gli stessi, e quando l’URL non è raggiungibile si usa la copia scaricata in precedenza.
• Il controllo dei file di report cambiati esegue una passata alla volta. Su un’unità di rete lenta due passate vedevano la stessa modifica, e la copertura veniva caricata due volte.
• «Dall’ultima esecuzione» sopravvive a un ricaricamento di report invariati. Una modifica delle impostazioni o un aggiornamento faceva dell’esecuzione a schermo la propria ultima esecuzione, e ogni cambiamento rispetto all’esecuzione precedente spariva. Una rilettura del genere non viene più nemmeno conservata nella cronologia.

Modificato

• Un file di copertura che scegliete, e il report che un’esecuzione di test scrive, vengono ricordati per voi invece di essere scritti in .vscode/settings.json. Quel file è spesso sotto commit, quindi un’esecuzione di test lasciava nel repository una modifica che nessuno aveva chiesto. I percorsi già presenti in coverageFile.paths continuano a funzionare.

Corretto

• Una soluzione .NET con due o più progetti di test non perde più la copertura di tutti i progetti tranne uno. dotnet test scriveva un report per progetto e tutti venivano spostati sullo stesso coverage/coverage.cobertura.xml, così veniva caricato solo l’ultimo. Una cartella del genere ora esegue dotnet test una volta per progetto di test, ogni report va in coverage/<Project>/, e l’esecuzione di un solo progetto sostituisce soltanto il report di quel progetto.
• Salvare più file insieme esegue i test di ogni file salvato. Con testRun.onSave venivano eseguiti solo i test dell’ultimo file; i salvataggi che arrivano mentre un’esecuzione è in corso vengono conservati ed eseguiti insieme dopo di essa.
• Run This Test with Coverage e le esecuzioni per test eseguono esattamente ciò che nominano. Il filtro .NET confrontava per sottostringa: Total eseguiva anche TotalTax. Un test viene ora eseguito con il suo nome esatto, una classe con il suo nome seguito da un punto, e un test in una classe annidata viene trovato (Outer+Inner).
• Un test jest o vitest il cui titolo contiene (, + o $ viene eseguito. Il titolo veniva passato a -t, che legge un’espressione regolare, così un test del genere non corrispondeva a nulla e nulla veniva eseguito.
• Run This Test with Coverage legge i file di test VB e F#. <Fact> sopra Public Sub, e [<Fact>] sopra let o member, non venivano mai riconosciuti.
• Annullare un’esecuzione di test termina ogni processo che ha avviato. Veniva terminata solo la shell, e dotnet test continuava dietro di essa. Anche chiudere Visual Studio annulla l’esecuzione.
• Digitare durante un’esecuzione avviata da un salvataggio non sposta più i segni. Sono ancorati al testo che l’esecuzione ha misurato.
• Una soluzione su una condivisione di rete esegue lì i suoi test. L’esecuzione partiva in C:\Windows, perché l’interprete dei comandi non accetta un percorso \\server\share come propria cartella.

Corretto

• Una soluzione .NET con due o più progetti di test non perde più la copertura di tutti i progetti tranne uno. dotnet test scriveva un report per progetto e tutti venivano spostati sullo stesso coverage/coverage.cobertura.xml, così veniva caricato solo l’ultimo. Una cartella del genere ora esegue dotnet test una volta per progetto di test, ogni report va in coverage/<Project>/, e l’esecuzione di un solo progetto sostituisce soltanto il report di quel progetto.
• Salvare più file insieme esegue i test di ogni file salvato. Con testRun.onSave venivano eseguiti solo i test dell’ultimo file; i salvataggi che arrivano mentre un’esecuzione è in corso vengono conservati ed eseguiti insieme dopo di essa.
• Run This Test with Coverage e le esecuzioni per test eseguono esattamente ciò che nominano. Il filtro .NET confrontava per sottostringa: Total eseguiva anche TotalTax. Un test viene ora eseguito con il suo nome esatto, una classe con il suo nome seguito da un punto, e un test in una classe annidata viene trovato (Outer+Inner).
• Un test jest o vitest il cui titolo contiene (, + o $ viene eseguito. Il titolo veniva passato a -t, che legge un’espressione regolare, così un test del genere non corrispondeva a nulla e nulla veniva eseguito.
• Un titolo di test con virgolette arriva intero al terminale. Un comando con \" tra virgolette si spezzava alla prima.
• Run This Test with Coverage legge i file di test VB e F#. <Fact> sopra Public Sub, e [<Fact>] sopra let o member, non venivano mai riconosciuti.
• Un task di test che termina senza avviare un processo non lascia più Run Tests with Coverage in attesa per sempre. Il comando termina e dice che l’esecuzione non ha scritto nulla.

Aggiunto

• Quali test hanno eseguito questa riga. Dove il report lo registra — coverage.py con --show-contexts, i metodi tracciati di OpenCover, un tracefile lcov scritto per test — il CodeLens di una funzione dice quanti test l'hanno eseguita, e Show Tests That Ran This Line li elenca, i più attivi per primi, e apre quello scelto. Per un'esecuzione dotnet test, testRun.perTest esegue i test una classe alla volta, così ogni report dice quale classe l'ha scritto.
• Copertura dopo ogni salvataggio. Con testRun.onSave, salvare un sorgente esegue i test che lo coprono, con copertura, e il margine segue. In una soluzione .NET vengono eseguiti solo i progetti di test che fanno riferimento al progetto del file salvato; più salvataggi di fila sono un'unica esecuzione.
• Run This Test with Coverage. Con il cursore in un metodo di test, in una classe di test o in un describe, o in un file di test, un solo comando esegue esattamente quello con copertura — dotnet test --filter, jest/vitest -t o un node id di pytest — e carica ciò che ha scritto. Il test è letto dal testo, quindi funziona per C#, VB, F#, JavaScript, TypeScript e Python senza servizio di linguaggio.
• Exclude from Coverage, e due filtri .NET. Un clic destro su una riga dell'albero di copertura, o Exclude This File from Coverage sul file aperto, aggiunge il file o la cartella a fuciniCoverage.ignore, ed esce da ogni totale. ignore.namespaces lascia fuori i file di un namespace (*.Migrations), e ignore.attributes la classe, il metodo o la proprietà sotto un attributo — ExcludeFromCodeCoverage per impostazione predefinita, che OpenCover, dotCover e un lcov convertito non rispettano.
• Exclude Selection from Coverage. Selezionate le righe e sceglietela dalla lampadina o dal menu contestuale dell'editor: sopra una classe, un metodo o una proprietà .NET scrive [ExcludeFromCodeCoverage] — in forma breve se il file importa già System.Diagnostics.CodeAnalysis — e altrove LCOV_EXCL_LINE o una coppia LCOV_EXCL_START/STOP nel commento proprio del linguaggio. Un marcatore già presente non viene raddoppiato.
• Namespace, classi e metodi. Per un report .NET che nomina le sue classi — Cobertura, Coverlet, OpenCover — un elenco Folders / Namespaces mostra la stessa esecuzione per namespace, classe e metodo, con lo stesso ordinamento e lo stesso filtro; una riga di metodo apre il file sul metodo. I tipi generati dal compilatore, come <>c e le macchine a stati async, confluiscono nella classe per cui sono stati generati.
• Una casella di ricerca sopra l'albero di copertura. Digitate parole per tenere le righe il cui nome o percorso le contiene tutte, o un confronto — < 80%, lines >= 90, branches = 0 — per tenere le righe il cui valore lo soddisfa; entrambi insieme richiedono entrambi. Vengono cercate anche le righe dei metodi e gli hotspot di rischio; Escape cancella.
• Run Native Project with Coverage. Il progetto di avvio C++, dal menu Tools: un progetto ClangCL viene ricompilato con la strumentazione di copertura di clang in coverage/native/, eseguito, e il suo report caricato; qualsiasi altro set di strumenti gira sotto OpenCppCoverage dove è installato, e dove nessuna delle due cose è possibile una frase dice cosa installare.
• Sessioni di copertura e un andamento. Start Coverage Session, e ogni esecuzione caricata da quel momento si somma alle precedenti — righe, branch e funzioni allo stesso modo: ciò che una qualsiasi di esse ha eseguito è coperto — così i test unitari, i test di integrazione e un giro nell'applicazione mostrano ciò che hanno raggiunto insieme. Sotto la barra degli strumenti, la copertura delle righe della cronologia salvata è disegnata come andamento, un punto per esecuzione.
• Compare Two History Runs, come in VS Code: scegliete due esecuzioni conservate e i file che si sono mossi tra di esse vengono elencati dalla più vecchia alla più recente, qualunque sia stata scelta per prima.
• Compare with CI Baseline. baseline.report indica il report che la build del vostro branch principale pubblica — un URL, scaricato con remote.headers, o un file scaricato — e ogni caricamento viene misurato rispetto a esso: la scheda della barra di stato dice dove si trova questa esecuzione, e Compare with CI Baseline elenca i file che si sono mossi. La baseline passa per la stessa lista di esclusioni dell'esecuzione, così i totali si confrontano alla pari.
• Dove trovarli. I nuovi comandi sono in Tools > Coverage Studio e nel menu contestuale dell'editor; Show Tests That Ran This Line è anche Ctrl+Shift+U, T, e Exclude Selection from Coverage è un'azione della lampadina.

Corretto

• Il report di un'esecuzione di test non porta più il vostro nome utente e di macchina. Il collector Code Coverage di Microsoft chiama il suo report <user>_<machine>_<stamp>.cobertura.xml, e quel nome compariva nell'albero e in ogni sua schermata; ora il report viene rinominato in coverage.cobertura.xml prima di essere caricato.
• Di un file generato si diceva che lo lasciava fuori fuciniCoverage.ignore. Ogni file escluso è ora contato sotto l'impostazione che lo ha escluso — ignore, ignore.generated o ignore.namespaces — così il nome mostrato è quello da cambiare.
• Un tracefile lcov scritto per test viene letto come un record per file, con le sezioni dei test sommate, come lo legge VS Code; prima il record di ogni test era un file a sé.
• Il log dice cosa un parser ha tralasciato. I file in cui un parser non ha trovato nulla da strumentare (FUCINI_PARSE_030) e il resoconto che un report dà delle proprie lacune (FUCINI_PARSE_031, il MissingPdb di OpenCover) vengono scritti nel log, come li scrive VS Code.
• Un header di macro non compare più nell'albero al 100%. llvm-cov e gcov attribuiscono gli usi di una macro alle righe che la definiscono; i branch e le funzioni su righe escluse ora se ne vanno con le righe, e un file rimasto senza nulla di misurabile viene tolto dall'esecuzione e nominato nell'output (FUCINI_EXCLUDE_001).
• Cinque report rifiutati come formato non supportato vengono riconosciuti. Il JaCoCo XML di Kover, un report Stryker.NET, un report NCover, un vecchio resultset SimpleCov e un report SonarQube di molti file vuoti vengono ora riconosciuti da ciò che portano in testa. Un report Clover o SonarQube i cui percorsi contengono la parola cobertura non viene più letto come Cobertura.
• Numeri che concordano con gli strumenti che li hanno scritti. Il valore dei branch di una build MC/DC corrisponde a llvm-cov report; i branch di eccezione di LCOV 2 (BRDA:12,e0,1,3) contano; una funzione llvm-cov è dichiarata solo nel file che la definisce; un blocco Go elencato da due binari di test somma i suoi conteggi; una decisione Cobertura riportata da due classi e una riga JaCoCo elencata due volte conservano tutti i loro rami, una volta.
• Altre minori. Un tracefile interrotto a metà scrittura non perde più un file; gcov -t su più file .gcda dà un file ciascuno, le istanziazioni di template sono lette una volta e conteggi come 1.20k di gcov -H vengono conservati; i file GNATcoverage non sono più tutti segnalati come cambiati rispetto alla loro copertura; un mutante Stryker in sospeso o un'esecuzione PIT interrotta non contano più contro il punteggio.
• Una modifica a mano del file delle impostazioni viene applicata quando viene salvato, come VS Code applica una modifica delle impostazioni.

Aggiunto

• Quali test hanno eseguito questa riga. Dove il report lo registra — coverage.py con --show-contexts, i metodi tracciati di OpenCover, un tracefile lcov scritto per test — il CodeLens di una funzione dice quanti test l'hanno eseguita, e Show Tests That Ran This Line li elenca, i più attivi per primi, e apre quello scelto. Per un'esecuzione dotnet test, testRun.perTest esegue i test una classe alla volta, così ogni report dice quale classe l'ha scritto.
• Copertura dopo ogni salvataggio. Con testRun.onSave, salvare un sorgente esegue i test che lo coprono, con copertura, e il margine segue. In una soluzione .NET vengono eseguiti solo i progetti di test che fanno riferimento al progetto del file salvato; più salvataggi di fila sono un'unica esecuzione.
• Run This Test with Coverage. Con il cursore in un metodo di test, in una classe di test o in un describe, o in un file di test, un solo comando esegue esattamente quello con copertura — dotnet test --filter, jest/vitest -t o un node id di pytest — e carica ciò che ha scritto. Il test è letto dal testo, quindi funziona per C#, VB, F#, JavaScript, TypeScript e Python senza servizio di linguaggio.
• Exclude from Coverage, e due filtri .NET. Un clic destro su una riga dell'albero di copertura, o Exclude This File from Coverage sul file aperto, aggiunge il file o la cartella a fuciniCoverage.ignore, ed esce da ogni totale. ignore.namespaces lascia fuori i file di un namespace (*.Migrations), e ignore.attributes la classe, il metodo o la proprietà sotto un attributo — ExcludeFromCodeCoverage per impostazione predefinita, che OpenCover, dotCover e un lcov convertito non rispettano.
• Exclude Selection from Coverage. Selezionate le righe e sceglietela dalla lampadina o dal menu contestuale dell'editor: sopra una classe, un metodo o una proprietà .NET scrive [ExcludeFromCodeCoverage] — in forma breve se il file importa già System.Diagnostics.CodeAnalysis — e altrove LCOV_EXCL_LINE o una coppia LCOV_EXCL_START/STOP nel commento proprio del linguaggio. Un marcatore già presente non viene raddoppiato.
• Namespace, classi e metodi. Per un report .NET che nomina le sue classi — Cobertura, Coverlet, OpenCover — un elenco Folders / Namespaces mostra la stessa esecuzione per namespace, classe e metodo, con lo stesso ordinamento e lo stesso filtro; una riga di metodo apre il file sul metodo. I tipi generati dal compilatore, come <>c e le macchine a stati async, confluiscono nella classe per cui sono stati generati.
• Una casella di ricerca sopra l'albero di copertura. Digitate parole per tenere le righe il cui nome o percorso le contiene tutte, o un confronto — < 80%, lines >= 90, branches = 0 — per tenere le righe il cui valore lo soddisfa; entrambi insieme richiedono entrambi. Vengono cercate anche le righe dei metodi e gli hotspot di rischio; Escape cancella.
• Sessioni di copertura e un andamento. Start Coverage Session, e ogni esecuzione caricata da quel momento si somma alle precedenti — righe, branch e funzioni allo stesso modo: ciò che una qualsiasi di esse ha eseguito è coperto — così i test unitari, i test di integrazione e un giro nell'applicazione mostrano ciò che hanno raggiunto insieme. Sotto la barra degli strumenti, la copertura delle righe della cronologia salvata è disegnata come andamento, un punto per esecuzione.
• Compare with CI Baseline. baseline.report indica il report che la build del vostro branch principale pubblica — un URL, scaricato con remote.headers, o un file scaricato — e ogni caricamento viene misurato rispetto a esso: la scheda della barra di stato dice dove si trova questa esecuzione, e Compare with CI Baseline elenca i file che si sono mossi. La baseline passa per la stessa lista di esclusioni dell'esecuzione, così i totali si confrontano alla pari.

Corretto

• Il report di un'esecuzione di test non porta più il vostro nome utente e di macchina. Il collector Code Coverage di Microsoft chiama il suo report <user>_<machine>_<stamp>.cobertura.xml, e quel nome compariva nell'albero e in ogni sua schermata; ora il report viene rinominato in coverage.cobertura.xml prima di essere caricato.
• Un'esecuzione di test falliva su Windows quando il terminale è PowerShell. Le virgolette attorno a Code Coverage;Format=cobertura si perdevano verso pwsh, che leggeva il ; come fine del comando; la ricetta viene ora passata al terminale parola per parola e quotata per la shell che avvia.
• Di un file generato si diceva che lo lasciava fuori fuciniCoverage.ignore. Ogni file escluso è ora contato sotto l'impostazione che lo ha escluso — ignore, ignore.generated o ignore.namespaces — così il nome mostrato è quello da cambiare.
• Un header di macro non compare più nell'albero al 100%. llvm-cov e gcov attribuiscono gli usi di una macro alle righe che la definiscono; i branch e le funzioni su righe escluse ora se ne vanno con le righe, e un file rimasto senza nulla di misurabile viene tolto dall'esecuzione e nominato nell'output (FUCINI_EXCLUDE_001).
• Cinque report rifiutati come formato non supportato vengono riconosciuti. Il JaCoCo XML di Kover, un report Stryker.NET, un report NCover, un vecchio resultset SimpleCov e un report SonarQube di molti file vuoti vengono ora riconosciuti da ciò che portano in testa. Un report Clover o SonarQube i cui percorsi contengono la parola cobertura non viene più letto come Cobertura.
• Numeri che concordano con gli strumenti che li hanno scritti. Il valore dei branch di una build MC/DC corrisponde a llvm-cov report; i branch di eccezione di LCOV 2 (BRDA:12,e0,1,3) contano; una funzione llvm-cov è dichiarata solo nel file che la definisce; un blocco Go elencato da due binari di test somma i suoi conteggi; una decisione Cobertura riportata da due classi e una riga JaCoCo elencata due volte conservano tutti i loro rami, una volta.
• Altre minori. Un tracefile interrotto a metà scrittura non perde più un file; gcov -t su più file .gcda dà un file ciascuno, le istanziazioni di template sono lette una volta e conteggi come 1.20k di gcov -H vengono conservati; i file GNATcoverage non sono più tutti segnalati come cambiati rispetto alla loro copertura; un mutante Stryker in sospeso o un'esecuzione PIT interrotta non contano più contro il punteggio.

Modificato

• Niente più FUCINI_ENCODING_001 a ogni caricamento. Un report senza byte-order mark viene letto come UTF-8, come lo scrive ogni strumento, senza una nota che lo dica.

Aggiunto

• Una voce relativa con una wildcard viene cercata a qualsiasi profondità. *.lcov.info in coverageFile.paths trova il file ovunque sia sotto la cartella di base, come VS Code ha sempre letto una voce così; una voce assoluta — ${workspaceFolder}/build/coverage-merged/*.lcov.info, ** per qualsiasi profondità — guarda esattamente dove dice, come prima.
• Osservato dove comparirà il report. L’osservazione copre le cartelle che le impostazioni nominano, che un report ci sia già o no: la cartella di un file assoluto, le cartelle prima di una wildcard — con tutto ciò che sta sotto quando il pattern scende nelle sottocartelle — e la cartella di base per una wildcard relativa. Un report che una build scrive lì si carica da solo; una scrittura su qualsiasi altro file in quelle cartelle viene ignorata.

Corretto

• Un report JSON di llvm-cov veniva rifiutato come formato non supportato. Il formato si riconosce dai primi 4096 caratteri, e llvm-cov scrive il suo marcatore "type": "llvm.coverage.json.export" proprio alla fine; un export il cui primo record di file porta molti rami ed espansioni di macro annidate non aveva nient’altro di riconoscibile in quella porzione iniziale. Un report del genere si riconosce ora dal suo inizio, {"data":[{"files":[, che nessun altro formato ha.
• Lo stesso per gcov --json-format. gcov scrive le funzioni di un file prima delle sue righe, e un file di una dozzina di funzioni non ha nemmeno una voce di riga nella porzione iniziale esaminata; ora lo identifica la chiave gcc_version del documento stesso.

Aggiunto

• Una wildcard in una voce assoluta di coverageFile.paths. ${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 vengono cercate, il resto è il pattern sotto di esse, come l’edizione per Visual Studio ha sempre letto una voce così. Prima, una voce assoluta veniva cercata com’era scritta, così una con un asterisco non corrispondeva a nulla — e, essendo una wildcard, non veniva nemmeno mai segnalata come priva di corrispondenze. Un report che compare lì in seguito viene caricato dall’osservatore o dal polling come una voce letterale; una wildcard che non corrisponde a nulla non viene segnalata, perché potrebbe aspettare una build.

Corretto

• Un report JSON di llvm-cov veniva rifiutato come formato non supportato. Il formato si riconosce dai primi 4096 caratteri, e llvm-cov scrive il suo marcatore "type": "llvm.coverage.json.export" proprio alla fine; un export il cui primo record di file porta molti rami ed espansioni di macro annidate non aveva nient’altro di riconoscibile in quella porzione iniziale. Un report del genere si riconosce ora dal suo inizio, {"data":[{"files":[, che nessun altro formato ha.
• Lo stesso per gcov --json-format. gcov scrive le funzioni di un file prima delle sue righe, e un file di una dozzina di funzioni non ha nemmeno una voce di riga nella porzione iniziale esaminata; ora lo identifica la chiave gcc_version del documento stesso.

Aggiunto

• Scegliere o combinare i report di un file. Fate clic con il tasto destro su un file nella finestra Coverage e scegliete Choose Coverage Source... — offerto dove più di un report caricato lo misura — oppure usate Tools > Coverage Studio > Choose Coverage Source for This File...: ogni report con i propri numeri, poi Combine them — agree (coperta solo dove ogni report ha eseguito una riga: una base di codice, due compilatori) e — union (coperta dove l’ha fatto uno qualsiasi: più suite di test di una stessa build), per il file, la sua cartella o un pattern. Le righe su cui i report discordano sono in verde acqua nel margine e nell’Annotated Source, con ciò che ha detto ciascun report; la riga del file indica i report e il numero di righe contese, e la barra di stato ed entrambe le schede dicono da dove vengono i numeri.
• Rosso, ambra e verde. Gutter: Coverage colora di verde ogni riga coperta accanto al rosso e all’ambra — la modalità per chi si aspettava che un file al 100% fosse verde. Le cinque tinte della heatmap sono impostazioni (heatmap.colors, heatmap.colorsDark), e la finestra delle impostazioni mostra l’anteprima di ogni colore mentre lo si sceglie.

Corretto

• Il numero del file nella barra di stato è quello della sua scheda. Una metrica vuota — l’MC/DC di un file senza decisioni — contava come 100% nell’elemento e per niente nella scheda che apre.
• Un header di costanti non indica più 0% o 100%. Le direttive del preprocessore contano come non-codice, come i commenti, quando excludeComments è attivo.

Aggiunto

• Scegliere o combinare i report di un file. coverageFile.sources decide, file per file, quale di più report caricati parla per esso — oppure li combina: agree conta una riga come coperta solo dove ogni report l’ha eseguita e segna in verde acqua le righe su cui discordano; union dove l’ha fatto uno qualsiasi. Choose Coverage Source... su una riga della vista Coverage o per il file aperto scrive la regola al posto vostro. Fa parte dei piani a pagamento; su Community decide il report più recente.
• Rosso, ambra e verde, e una modalità del gutter a un clic. La modalità coverage colora di verde le righe coperte; le tinte della heatmap sono impostazioni con anteprima dal vivo nel pannello delle impostazioni; un pulsante nella barra di stato e Alt+G fanno passare il gutter tra spento, non coperte, coverage e heatmap.

Corretto

• Il numero del file nella barra di stato è quello della sua scheda. Una metrica vuota — l’MC/DC di un file senza decisioni — contava come 100% nell’elemento e per niente nella scheda che apre.
• Un header di costanti non indica più 0% o 100%. Le direttive del preprocessore contano come non-codice, come i commenti, quando excludeComments è attivo.

Modificato

• La finestra Licence chiede solo il codice. I quattro pulsanti dei piani non ci sono più: un codice di abbonamento o di invito indica un pool, e il pool conosce il proprio piano, quindi non c’era nulla che una persona potesse rispondere meglio del codice stesso — e un invito Business incollato con Pro ancora selezionato veniva rifiutato per piano sbagliato. Incollate il codice e premete Activate.

Modificato

• Enter Subscription Code chiede solo il codice. La domanda sul piano non c’è più: il codice indica un pool e il pool conosce il proprio piano, quindi il server prosegue da lì e non rifiuta più un codice come appartenente al piano sbagliato. I link a un clic nelle e-mail sono invariati; le e-mail di attivazione non hanno più il passaggio "scegli il tuo piano", e lo stesso codice attiva Coverage Studio per Visual Studio senza bisogno di VS Code.

Aggiunto

• Coverage dopo ogni esecuzione dei test. Collect Coverage in Test Explorer… mette un .runsettings con il collector Cobertura di Microsoft accanto alla soluzione — raccolto da sé con Tools → Options → Test → Auto detect runsettings files attivo, o selezionato una volta sotto Test → Configure Run Settings; da quel momento ogni esecuzione di Test Explorer scrive un report sotto il progetto di test, e viene caricato nell'istante in cui compare, unito a tutto ciò che le impostazioni nominano. Nulla si aggancia a Test Explorer, così Visual Studio 2026 e Microsoft.Testing.Platform funzionano così come sono. Run Tests with Coverage riconosce dotnet test, vitest, jest, pytest, go, cargo, maven, gradle, phpunit e ctest, li esegue con la coverage attiva nella finestra Output e carica ciò che hanno scritto; un progetto di test senza coverlet.collector viene eseguito con il collector fornito dall'SDK di test.
• Dall'ultima esecuzione. Ogni caricamento viene confrontato con il precedente: un triangolo nel margine su ogni riga che ha iniziato o smesso di essere eseguita, la tendenza accanto al punteggio, e Compare with Last Run per i file i cui numeri si sono mossi. history.enabled conserva le esecuzioni tra un riavvio e l'altro; gitDiff.enabled riduce l'esecuzione alle righe che il vostro ramo ha cambiato.
• I gate e l'Error List. Check Coverage Thresholds giudica l'esecuzione rispetto a threshold.*; con compliance.diagnostics, problems.enabled, problems.perLine o deadCode.enabled i rilievi stanno nell'Error List accanto a quelli del compilatore, ciascuno apre il suo file.
• Report, esportazioni e un badge. Show Annotated Source apre il file attivo come pagina nell'area dei documenti — ogni riga nel suo colore, i rilievi accanto — che scorre con l'editor in entrambe le direzioni. Open HTML Report e Generate Full HTML Report scrivono l'esecuzione in htmlReport.outputDir e aprono il browser. Export Coverage Report… scrive CSV per file o per funzione, Markdown, LCOV, Cobertura, SARIF, un badge SVG o Fucini JSON. Generate Coverage Badge tiene il badge nel repository, dopo ogni caricamento con badge.autoUpdate.
• Risk hotspots e filtri di riga nella finestra Coverage, come in VS Code: le funzioni dove il codice complesso incontra poca coverage, dalla peggiore in poi; e un menu a discesa accanto all'ordinamento per tutti i file, i file con lacune, i file non testati, o i file cambiati dall'ultima esecuzione.
• Un file di impostazioni nella radice della soluzione. fucini-coverage.json accanto alla soluzione viene letto dopo .vscode/settings.json e scritto dalla finestra di impostazioni quando è il file che esiste — per un team che preferisce non tenere una cartella .vscode. Entrambe le edizioni lo leggono.
• .NET senza cerimonie. ignore.generated lascia i file del designer, quelli generati, obj\ e le migrazioni fuori da ogni totale; testRun.skipWhenTestsFail mantiene sullo schermo l'ultima coverage buona quando un'esecuzione finisce in rosso.

Non ancora in questa edizione

• Il pannello Test Coverage è un'API di VS Code, ed Esplora soluzioni non può mostrare badge. Compare Two History Runs seguirà quando gli abbonati lo chiederanno.

Aggiunto

• Quali file mostrare. Un secondo menu a discesa nella barra degli strumenti della vista Coverage, accanto all'ordinamento: tutti i file, i file con lacune, i file non testati, o i file i cui numeri si sono mossi dall'esecuzione precedente. Le cartelle seguono i loro file e conservano i propri numeri. In ogni piano.
• Risk hotspots. Sotto l'albero: 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. Community vede il conteggio e il punteggio peggiore; l'elenco ordinato è Pro.
• dotnet test senza pacchetto. Run Tests with Coverage legge prima i file di progetto: dove nessuno fa riferimento a Coverlet, l'esecuzione usa il collector di Microsoft — --collect:"Code Coverage;Format=cobertura" — fornito con Microsoft.NET.Test.Sdk, e il suo report viene caricato come quello di Coverlet.
• I file .NET generati restano fuori. ignore.generated, attivo per impostazione predefinita, esclude *.Designer.cs, *.g.cs, *.generated.cs, *.razor.g.cs, AssemblyInfo, gli using globali, tutto ciò che sta sotto Migrations/ e sotto obj/ da ogni totale, pagina ed esportazione. Un file del designer che nessuno testa non costa più a una soluzione il suo gate.
• Un'esecuzione fallita conserva l'ultima coverage buona. Con testRun.skipWhenTestsFail, un'esecuzione che finisce con un test fallito lascia la coverage sullo schermo com'era, e lo dice nel riquadro Output. Disattivato per impostazione predefinita.

Modificato

• Un'esecuzione di Test Explorer viene trovata da sé. Senza nulla di configurato, i nomi noti includono ora la cartella TestResults/<run>/ di ogni progetto di test, non solo quella della cartella dello spazio di lavoro, e il <user>_<machine>_<date>.cobertura.xml del collector di Microsoft accanto a quello di Coverlet. Una soluzione .NET i cui test sono stati eseguiti in 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.

Aggiunto

• Una seconda estensione, per Visual Studio 2022 e 2026 — Community, Professional ed Enterprise. Lo stesso lettore dell'edizione per VS Code, così lo stesso report dà gli stessi numeri, alla cifra, in entrambi gli editor; e le stesse impostazioni fuciniCoverage.*, lette da .vscode/settings.json come dalle impostazioni utente di VS Code quando è sulla macchina. Non usa la code coverage propria di Visual Studio: in Visual Studio 2022 è una funzione Enterprise, e su Community e Professional questa è l'unica coverage che l'IDE mostrerà.
• Nell'editor: una barra nel margine per riga — rossa mai eseguita, ambra in parte, una mappa termica per visite — conteggi in linea, una riga sopra ogni funzione con la sua coverage, complessità, punteggio CRAP e MC/DC, strisce sulla barra di scorrimento, un hover che dice quale ramo non è stato preso, e un punto su una riga modificata dopo il report.
• La finestra Coverage (View → Other Windows → Coverage): ogni file con le sue metriche e un punteggio su tutti, ordinabile, con i file non misurati sotto; le voci Coverage e File della barra di stato, ognuna apre la scheda completa.
• Comandi sotto Tools → Coverage Studio, con accordi a due pressioni dopo Ctrl+Shift+U: N/P per la riga non coperta successiva e precedente, B per la prossima decisione parzialmente testata, R per ricaricare. La modalità watch ricarica quando il file che la vostra build scrive cambia.
• Getting Started, i sei passi con un pulsante per ciascuno, in 18 lingue; si apre da solo la prima volta.
• Impostazioni dall'ingranaggio nella barra degli strumenti della finestra Coverage, che scrive le impostazioni utente di questa edizione o il .vscode/settings.json della cartella e conserva i commenti di un file che modifica.
• Licenza: inclusa in ogni piano a pagamento. Una macchina dove Coverage Studio per VS Code è attivato non ha bisogno di altro — la chiave viene trovata da sola; ovunque altrove Tools → Coverage Studio → Licence… accetta il codice di abbonamento dalla vostra e-mail di attivazione. Senza abbonamento nessuna coverage viene letta: non c'è un livello gratuito in Visual Studio.

Non ancora in questa edizione

• Run Tests with Coverage e il pannello Test Coverage sono API di VS Code; Esplora soluzioni non può mostrare badge. La vista Annotated Source, il report HTML e le esportazioni, Check Thresholds, le voci dell'Error List, storico e tendenza, e la coverage delle diff seguono nell'ordine in cui gli abbonati le chiedono.

Aggiunto

• Un percorso guidato. Get started with Coverage Studio — sotto Help → Welcome → Walkthroughs, e aperto da solo dopo l'installazione — porta un nuovo utente in sei passi da un report di coverage alle righe che nessuno testa, ciascuno con un pulsante per il comando di cui parla. In tutte le diciotto lingue.
• L'id di installazione viene lasciato dove Coverage Studio per Visual Studio lo legge. L'edizione per Visual Studio verifica la chiave in license.key contro la stessa impronta e non può leggere l'archivio di stato di questa estensione; a ogni attivazione l'id viene ora scritto anche accanto all'archivio globale dell'estensione, così una macchina attivata in VS Code non ha bisogno di una seconda attivazione in Visual Studio. Un UUID casuale, legato a nulla, mai inviato da nessuna parte.

Modificato

• Un rimborso termina l'abbonamento. Un rimborso o uno storno approvato ora annulla subito l'abbonamento e il suo codice di attivazione non emette più chiavi; i rimborsi sono uno per cliente. Le chiavi già su una macchina continuano fino alla propria scadenza, come prima. La politica di rimborso dice esattamente cosa succede.

Corretto

• I nomi dei file nella vista Coverage si leggono a qualsiasi larghezza. Il nome era l’unica parte di una riga a restringersi — fino a sette caratteri in una normale barra laterale. Ora è disegnato per intero, e le colonne delle metriche, il punteggio e la barra gli scorrono sotto da sinistra, sfumando al taglio così che mezzo numero non si legga mai come un numero intero. Ogni valore resta nel tooltip della riga.
• Il contrassegno «il file è cambiato» segue il file. Dopo un caricamento seguiva la prima modifica e il primo ripristino, poi nulla lo muoveva più fino al caricamento successivo. Ora ogni salvataggio e ogni modifica su disco arriva.
• La barra degli strumenti della vista Coverage non spezza più le etichette dei pulsanti. In una barra laterale stretta ora va a capo tra i suoi controlli, e la casella di ordinamento passa su una riga propria.
• Il badge di copertura è gratuito anche nel selettore di esportazione. Generate Coverage Badge ha sempre scritto il badge SVG a ogni livello, mentre Export Coverage Report… rifiutava lo stesso file su Community. Ora lo scrivono entrambi.
• Show Worst-Covered Folders è concesso in licenza come le altre due liste. Nulla cambia su Community, dove tutte e tre sono gratuite e non conteggiate, né per alcuna chiave già emessa.

Aggiunto

• Una versione minima supportata. L’estensione legge ora, circa una volta alla settimana, una piccola policy firmata dal nostro server delle licenze. Quando una build è più vecchia della più vecchia ancora supportata, la prova e il livello gratuito si fermano e chiedono un aggiornamento; a una licenza a pagamento viene comunicata la data e continua prima a funzionare per un periodo di tolleranza. La lettura non invia nulla su di te né sulla tua installazione, e un’installazione che non riesce a raggiungere il server non viene mai fermata per questo. Oggi non è impostato alcun minimo.

Modificato

• Da questa versione la licenza è proprietaria. L’estensione era pubblicata con i termini MIT, che non si sono mai adattati a un prodotto venduto in abbonamento. Puoi installare e usare la build pubblicata entro i limiti del tuo piano, anche a fini commerciali; non puoi copiarla, modificarla, ridistribuirla né sottoporla a reverse engineering. Ciò che produce dai tuoi dati — report, esportazioni, badge — è tuo, e la vecchia condizione di attribuzione non c’è più. Una copia di una versione precedente resta sotto i termini con cui è arrivata.
• Il pulsante delle azioni sul percorso (⋯) non occupa spazio finché non si punta una riga. I 25 pixel che teneva riservati su ogni riga vanno ora al nome del file; compare subito dopo il nome al passaggio del puntatore, e nulla si sposta nella riga.

Corretto

• I tracefile LCOV 2 elencano ogni funzione una volta sola. FN:<riga>,<riga finale>,<nome> viene letto come lo scrive lcov 2.0 — prima ogni funzione compariva due volte, una come mai chiamata e una alla riga 0 — e con esso si leggono le coppie FNL:/FNA: di lcov 2.2.
• Un template C++ non viene più dipinto come mai eseguito perché un’istanziazione non lo era, e una funzione piena di macro torna a essere una funzione sola invece di una per macro.
• I testi del consenso dicono ciò che l’installazione invia davvero: nessuna pagina mensile del tuo codice, e il riepilogo d’uso porta il codice di richiesta con cui è stata emessa la tua chiave.

Aggiunto

• La copertura delle condizioni è una metrica a sé. a && b è una decisione e due condizioni, e una suite può prendere entrambi i rami senza vedere mai b falso. Ora ha una propria riga, colonna, esportazione, badge, peso nel punteggio (3, tra rami e MC/DC) e soglia — letta da BullseyeCoverage, da un export cond di TRACE32 e da -fcondition-coverage di GCC 14.
• I mutanti, dove sono. I report di PIT e Stryker vengono letti mutante per mutante: quelli sopravvissuti sono segnati sulla loro riga nell’editor, con la modifica e i test che l’hanno eseguita nel suggerimento, ed elencati nel report HTML e nel sorgente annotato.
• Quali test hanno eseguito questa riga. coverage.py con --show-contexts e OpenCover con -coverbytest dicono quali test hanno raggiunto una riga; il suggerimento del contatore li nomina.
• La parte di una riga eseguita che non è mai stata eseguita viene tinta nell’editor, e le funzioni C e C++ ricevono complessità e punteggio CRAP calcolati dai dati sui rami che llvm-cov porta già con sé.
• I progetti JaCoCo, Cobertura e Coverlet si caricano alla prima apertura, senza configurare nulla — compreso dove Maven, Gradle e dotnet test scrivono per impostazione predefinita.
• Ogni metrica accanto a ogni file, a qualsiasi larghezza, ordinata per il peso che ha nel punteggio, con ciò che non entra che scorre invece di sparire — e un conteggio sull’icona Coverage quando un tracefile si ricarica mentre guardi altrove.
• Un canale di anteprima per cui ci si può offrire volontari e un pulsante nella barra del titolo dell’editor che spegne la colorazione della copertura e riporta esattamente ciò che c’era.

Modificato

• Bullseye e TRACE32: la copertura dei rami non include più le condizioni. Le decisioni sono copertura dei rami e le condizioni copertura delle condizioni, quindi la cifra dei rami di un simile progetto cambia, e con essa il punteggio composito. Imposta whmWeights.conditions a 0 per il punteggio di prima.
• Il livello gratuito Community ha una dotazione settimanale: cinque a settimana per ciascuna delle azioni misurate, dove erano venti al giorno, e al limite vengono offerti un abbonamento o un pass di 7 giorni. Un’installazione già in uso mantiene i vecchi limiti per 30 giorni e ne viene informata una volta, con la data.
• La prova e il livello gratuito tengono un registro d’uso con il server delle licenze: un hash dell’id macchina di VS Code, l’edizione, il giorno in cui è iniziata la valutazione e i contatori delle azioni misurate — nient’altro, mai con una licenza a pagamento e mai atteso. Lo scambio con la telemetria è ora di 30 giorni, una volta sola.
• La pagina mensile di codice sorgente non c’è più — non viene più raccolta, conservata né inviata, per nessuno, e quella tenuta da una build precedente viene cancellata al primo avvio di questa.

Corretto

• La mappa di calore si legge nel verso giusto con un tema scuro. La sua scala andava dal giallo pallido al marrone scuro, così il ciclo più caldo aveva la barra più spenta. Un tema scuro ha ora una scala propria, dall'oliva spento all'arancione vivo.
• Il tooltip MC/DC al passaggio del mouse mostra di nuovo il suo dettaglio, e una decisione di llvm-cov conta correttamente le sue condizioni. La versione attuale di VS Code ripiegava il tooltip in una sola riga; e (a && b) || c veniva elencata con una condizione al 100% sotto un'intestazione che giustamente diceva 2 coppie su 3.
• Le funzioni C++ hanno il nome con cui le hai scritte: clamp_to<int> e gearbox::next_gear anziché ??$clamp_to@H@@YAHHHH@Z del linker, per llvm-cov, lcov e gcov.
• I conteggi delle righe di Istanbul coincidono con nyc, l'XML di dotnet-coverage viene letto, le righe :nocov: di SimpleCov vengono escluse anziché compromesse, e un report che contiene solo un riepilogo conserva le sue cifre in qualunque ordine vengano letti i report.
• Workspace multi-root: il report HTML non nomina più una cartella due volte, la vista Coverage intesta una cartella del workspace con il suo nome, e una regola pathRemap può indicare ${workspaceFolder} oltre a ${workspaceRoot}.

Aggiunto

• Tutto ciò che un report contiene viene mostrato. Chiamate di funzione, codice oggetto e un punteggio di mutazione ottengono una colonna nella vista Coverage, nel report HTML e nelle esportazioni CSV e Markdown, una riga nelle schede della barra di stato e un badge nel sorgente annotato — e una metrica che un report non contiene viene omessa anziché stampata come zero.
• Complessità e CRAP. Dove un report contiene la complessità ciclomatica (OpenCover, JaCoCo, Clover, Cobertura), ogni funzione ottiene un punteggio CRAP nel suo CodeLens, un file ottiene un Max CRAP che rimanda al metodo, e il report HTML elenca i Riskiest Methods.
• Di più da ogni formato: rami con nome, righe escluse, intervalli di colonne all'interno della riga, lo strumento, la versione e la data del report, e gli avvisi che uno strumento vi ha scritto.
• Pesi opzionali per il codice oggetto e il punteggio di mutazione nel punteggio composito, entrambi a 0 finché non li imposti.

Modificato

• Le soglie predefinite non sono più al 100%. Una soglia che non hai impostato vale ora righe 80, funzioni 80, regioni 75, rami 70 e punteggio composito 75, senza alcun gate su MC/DC, istanziazioni, chiamate di funzione o codice oggetto — ciò che si può pretendere da un progetto ordinario. fuciniCoverage.threshold.profile: "safety" riporta ogni gate a 100, esattamente come prima, e una soglia che hai impostato tu prevale su entrambi i profili. Se facevi affidamento sui vecchi valori predefiniti, il giudizio è più indulgente finché non selezioni safety; un'installazione già in uso in precedenza ne viene informata una sola volta, con un pulsante che lo imposta.
• Una metrica senza gate mostra un trattino neutro nelle schede anziché un segno di spunta o una croce, e il pannello delle impostazioni mostra in anteprima il verdetto con i gate effettivamente in vigore.

Corretto

• La copertura in un buffer con modifiche non salvate torna allineata. Un'esecuzione caricata mentre un file aveva modifiche non salvate spostava ogni segno, hover e CodeLens di tante righe quante quelle modifiche li avevano spinti. Le modifiche vengono ora ricavate dal file su disco, e una riga intera incollata sopra un'altra non conta più quella riga come modificata.
• Le fusioni e i record LCOV ripetuti si sommano. Un tracefile più recente non conserva più i riepiloghi di rami e MC/DC dell'esecuzione precedente, e un file elencato due volte in uno stesso tracefile viene combinato come fa genhtml.
• La chiave di licenza resta sulla propria macchina. Settings Sync non la porta più su altre installazioni, dove bloccava la copertura; una chiave Business, Enterprise o Pro Plus scaduta si rinnova da sola fino a 45 giorni dopo la scadenza.
• I tracefile remoti vengono scaricati con più cura. Gli remote.headers restano sulla loro origine attraverso i reindirizzamenti, uno scaricamento rinuncia dopo 30 secondi, una pagina di accesso viene rifiutata anziché messa in cache, e una finestra aperta offline carica l'ultima copia scaricata. L'auto-aggiornamento installa solo la propria edizione.
• Parser: i conteggi di riga di llvm-cov coincidono con llvm-cov show, le decisioni OpenCover di metodi diversi non si sovrascrivono più, xccov, TRACE32 ed EMMA conservano le cifre di riga, le classi Cobertura che condividono un file sono un solo file, i rapporti aggregati JaCoCo vengono letti, e la mappatura dei percorsi risolve .. e confronta segmenti interi.
• Nell'editor: la cronologia è tenuta per area di lavoro, i segni restano sui file reali e non sul riquadro HEAD di un editor di diff, le righe oltre la fine di un file non vengono disegnate, i badge dell'Esplora risorse su Windows funzionano con i percorsi C:\…, e le esecuzioni grandi si consultano più in fretta.

Aggiunto

• Invia rapporto di diagnostica. Lo offrono le notifiche di caricamento, scaricamento remoto, fusione, confronto della cronologia o chat non riusciti. Mostra esattamente il JSON che verrebbe inviato, con un campione di file di 4 KB facoltativo, un commento e un indirizzo di risposta, e non invia nulla finché non si fa clic su Invia.
• Rapporti di errore. Un errore FUCINI_* viene segnalato senza contenuto dei file, percorsi o nomi quando il livello di telemetria di VS Code è all o error. Tre righe di log hanno un codice proprio: FUCINI_REMOTE_002, FUCINI_REMOTE_003 e FUCINI_GITDIFF_002, ciascuno descritto nella guida utente.

Modificato

• Ogni percentuale di copertura ha due decimali, troncati anziché arrotondati: 87.43%, e 100.00% solo quando la copertura è esattamente 100.
• Le soglie decidono sul valore esatto. Finora ogni percentuale veniva prima arrotondata a un intero, così 89,6% superava una soglia del 90%. Un progetto che passava solo grazie all'arrotondamento mostrerà ora NON-COMPLIANT finché la copertura non raggiunge davvero la soglia.
• La telemetria è giornaliera. Ogni installazione invia un piccolo messaggio di licenza giornaliero al livello di telemetria all di VS Code; con telemetry.enabled attivo, il riepilogo di utilizzo parte ogni giorno anziché ogni mese. Alle installazioni che hanno sbloccato funzioni in cambio di telemetria viene chiesto prima che le loro condizioni cambino.

Aggiunto

• La vista Coverage segnala un aggiornamento disponibile, e continua a segnalarlo. Una barra sopra il banner della licenza indica la nuova versione accanto a quella che hai, con gli stessi tre pulsanti della notifica di aggiornamento: «Scarica & installa», «Visualizza changelog» e «Salta questa versione». Anche l’icona della vista nella barra delle attività mostra un badge, così si vede pure a vista chiusa. La notifica compariva una sola volta, al controllo automatico, e un clic altrove la nascondeva fino al controllo successivo, un giorno dopo; la barra resta finché l’aggiornamento non viene installato o saltato, o finché fuciniCoverage.update.checkForUpdates non viene disattivato, e sopravvive al ricaricamento della finestra.

Modificato

• I piccoli ping partono al massimo una volta al giorno, insieme. Un aggiornamento, un cambio di licenza, un nuovo formato di copertura e un file che non si riusciva a leggere erano ciascuno un ping a sé, inviato non appena veniva notato — e su alcune installazioni notato di nuovo a ogni sessione: una postazione revocata segnalava la revoca a ogni avvio, e passare tra aree di lavoro con formati diversi segnalava ogni volta un insieme “nuovo”. Ora vengono raccolti e inviati come un unico ping, al massimo una volta al giorno. Un giorno senza nulla da segnalare non invia nulla.
• Viene segnalato solo ciò che è davvero cambiato. Una licenza che cambia e torna com’era nell’arco della giornata non segnala nulla, e i formati sono tutti quelli che l’installazione ha caricato, non solo quelli dell’ultima area di lavoro. Il ping di installazione e l’avviso di disinstallazione partono ancora subito, e non viene raccolto nulla di nuovo.
• L’interruttore di telemetria di VS Code ora vale anche per i piccoli ping. Con telemetry.telemetryLevel impostato su off, per il ping giornaliero non viene raccolto né inviato nulla; finora lo rispettavano solo il riepilogo mensile e l’avviso di rimozione. Il ping di installazione una tantum è invariato.
• Un mese che finisce mentre l’editor è inattivo viene comunque segnalato. Il riepilogo mensile veniva controllato solo dopo aver caricato una copertura, quindi un’installazione non più usata non inviava mai il suo ultimo mese. Ora viene controllato anche ogni ora mentre VS Code è aperto — sempre solo con la telemetria attiva, e sempre al massimo una volta ogni 30 giorni.

Corretto

• Un ping rifiutato dal server non conta più come inviato. Qualsiasi risposta del server, errore compreso, valeva come consegna, quindi un ping giornaliero rifiutato perdeva ciò che aveva raccolto e un ping di installazione rifiutato non veniva ritentato. Ora conta solo una risposta riuscita; un ping giornaliero o un riepilogo mensile rifiutato viene conservato e ritentato un giorno dopo.

Modificato

• Ogni valutazione riceve 14 giorni nuovi, una volta. Al primo avvio di questa versione, la prova si riapre su ogni installazione Pro senza licenza a pagamento — che sia scaduta da tempo o che le restassero ancora pochi giorni — e dura 14 giorni da quel giorno. Un breve avviso lo segnala quando accade. Una licenza a pagamento non è toccata, e l’edizione Community, che non ha una prova, resta invariata.
• Una licenza a pagamento dice «Attivato», in verde. Il banner della licenza mostrava a un abbonato «Attivato — 30 giorni rimanenti». Una chiave di abbonamento dura fino alla fine del periodo pagato e si rinnova con esso, quindi quel conto alla rovescia non avrebbe mai smesso di sembrare una prova in scadenza. Il titolo ora dice semplicemente Attivato, la data compare nei dettagli come «In vigore fino al», e il conto alla rovescia torna solo nell’ultima settimana prima che una chiave scada, accanto alla nota sul rinnovo imminente che c’era già.

Aggiunto

• «Enter Subscription Code» — e non viene chiesto nient’altro. Scelga il piano, incolli il codice dall’e-mail d’acquisto, confermi: la chiave di licenza viene emessa e applicata per lei. Finora l’unica strada dall’interno dell’editor era il questionario di valutazione — nome, e-mail, tipo di account, azienda, un sondaggio —, che è il modulo sbagliato da mettere davanti a chi ha già comprato. L’altra strada era il link vscode:// dell’e-mail, e diffidare di quel clic è sensato, non timoroso: un link così può essere innescato da qualunque pagina visitata, ed è precisamente per questo che l’attivazione chiede una conferma. Il comando è nella palette dei comandi, ed è un pulsante sul banner della licenza nel pannello della copertura e nella finestra di attivazione — in ogni stato, perché una licenza si sposta da una macchina all’altra e acquistare a metà della prova è il caso ordinario, non l’eccezione.
• Un modo per vedere i piani dalla prova stessa. La pagina dei prezzi era raggiungibile dalle schermate dell’edizione gratuita, ma non dalla finestra di attivazione né dal banner della licenza — l’unico posto che guarda davvero chi legge «3 giorni rimasti». A quel lettore venivano offerti un questionario e un suggerimento su settings.json, e nessun prezzo.

Modificato

• La finestra di attivazione e il banner della licenza non si aprono più con FCK1. Entrambi iniziavano con il suo codice di richiesta e con «incolli la chiave in settings.json», che è la via prevista quando il nostro server delle licenze non è raggiungibile affatto. Mostrata per prima, si leggeva come l’istruzione — così un cliente con un codice di abbonamento FCB1… veniva mandato su «Enter Activation Key», l’unico campo destinato con certezza a rifiutarlo. Entrambe restano, sotto le vie adatte a chi ha comprato, e descritte per quello che sono davvero.

Corretto

• «Request Activation Key» ora è davvero un comando. L’e-mail d’acquisto — e la pagina di attivazione, in ogni lingua — le dicono che, se il link con un clic non sopravvive al programma di posta, può eseguire Fucini Coverage: Request Activation Key dalla palette dei comandi, scegliere il piano e incollare il codice. Quel nome apparteneva alla barra del titolo del pannello e al link stesso, mai a un comando, quindi nella palette non c’era nulla sotto di esso — e la corrispondenza più vicina per nome, Enter Activation Key, accetta la chiave FCK1… emessa dal nostro server, non il codice FCB1… che l’e-mail porta con sé. Seguire le istruzioni la portava nell’unico campo destinato con certezza a rifiutare ciò che aveva in mano. Ora è un comando reale.
• La finestra di attivazione offre Richiedi licenza… anche mentre una prova o una chiave sono ancora valide. Prima veniva nascosta fino alla scadenza di una delle due, con il ragionamento che un’installazione funzionante non ha motivo di contattare il server delle licenze. Ma acquistare a metà della prova è il caso ordinario, non l’eccezione, e chi si trovava in quella posizione non aveva, dalla finestra, alcuna strada verso il campo in cui va il suo codice: i due pulsanti rimasti chiedevano una chiave che solo il riscatto del codice produce.

Aggiunto

• Una tavolozza per daltonici. Imposti colorScale.preset su colorblind e la copertura viene disegnata in vermiglio, arancione e blu (la tavolozza Okabe–Ito) invece di rosso, ambra e verde — gradiente, barre a margine, evidenziazione delle righe, badge di Esplora risorse e segni dall'ultima esecuzione. Un colore impostato da lei ha la precedenza.

Aggiunto

• Filtrare la copertura per test nella vista Test Coverage di VS Code. Quando un file di traccia nomina i suoi test — le sezioni TN: di lcov — ogni test diventa un elemento sotto Fucini Coverage nel Test Explorer, ogni file nella vista Test Coverage elenca i test che vi hanno eseguito qualcosa e sceglierne uno mostra le righe raggiunte da quel test.
• ${command:…} nelle impostazioni dei percorsi. ${command:cmake.buildDirectory}/coverage.info segue il kit CMake selezionato. Il comando viene eseguito prima di ogni rilevamento, per al massimo cinque secondi e solo in un’area di lavoro attendibile; se non riesce, la variabile resta com’è scritta e l’output spiega perché.
• Un avvio rapido in 30 secondi e un confronto con le alternative aprono ora la pagina del Marketplace e la home page.

Corretto

• Un file di traccia che registrava un file una volta per test lo contava una volta per test. I record ora vengono sommati per file di traccia, come li legge genhtml: il file conta una sola volta nei totali e, con più file di traccia caricati, nessun test perde le proprie righe.

Corretto

• L’ID di installazione ora viene salvato prima che qualcosa lo usi. La build 2 della 0.2026.72 ha smesso di ricalcolare l’ID a ogni chiamata, ma all’avvio nulla attendeva ancora che venisse scritto, quindi una finestra chiusa subito dopo l’apertura poteva ancora perderlo — e con esso l’impronta della macchina a cui è legata una chiave di attivazione. Ora l’avvio attende.
• Passare da Pro a Community mantiene valida la chiave di attivazione. Ogni edizione ha il proprio spazio di archiviazione dell’estensione, quindi Community partiva con un nuovo ID di installazione e una nuova impronta, mentre la chiave nelle impostazioni — compresa quella appena richiesta dal passaggio per lo sblocco gratuito — era legata a quello vecchio. Ora il passaggio trasferisce l’ID.

Sicurezza

• Gli aggiornamenti da fucini.software sono firmati e verificati prima dell’installazione. Ogni .vsix nel canale degli aggiornamenti porta un hash SHA-256 e una firma Ed25519 creata con una chiave che non si trova mai sul server web. L’aggiornamento integrato e il passaggio a Community verificano entrambi sul file scaricato e rifiutano qualsiasi altra cosa: la pagina di errore di un proxy, un download troncato, una build precedente in cache o un file che non è nostro. HTTPS da solo non basta: un proxy aziendale che ispeziona il TLS rifirma ogni connessione che vede.
• Ogni release ha un proprio nome file. Il canale degli aggiornamenti ora punta a un .vsix con numero di versione invece che a un file sovrascritto a ogni release, così una cache che ignora Cache-Control non può servire la build del mese scorso al posto di quella attuale. I link nella pagina di download restano invariati.

Aggiunto

• Vai alle decisioni testate in un solo senso. Next Partly-Tested Decision e la sua gemella precedente percorrono le diramazioni di cui alcuni rami sono stati eseguiti e altri mai. È la lacuna che la navigazione tra righe non coperte non può mostrare: una riga la cui istruzione è stata eseguita risulta coperta, e lo resta per quanti suoi rami non siano mai stati presi — if (a && b) raggiunto una volta con a falso è coperto al 100% per righe e testato a metà. Una fermata per decisione anziché per ramo, perché i rami di un if/else possono distare pagine, e saltare al quinto ramo di uno switch dice meno che saltare allo switch stesso. Le decisioni che nessun ramo ha mai raggiunto restano ai comandi per le righe non coperte, che lì si fermano già — e un file il cui report non registra alcuna diramazione lo dice, invece di sostenere che ogni decisione è stata testata in entrambi i sensi.
• Reload Coverage rilegge ciò che è già caricato. Con il monitoraggio disattivato, l’unica via verso numeri freschi dopo aver rieseguito i test passava per Load Coverage, che ripete il rilevamento e può tornare con un insieme diverso da quello a schermo. Questo comando rilegge esattamente ciò che è caricato ora, compresi i file di tracciamento scelti a mano che il rilevamento non ritroverebbe mai.
• Copy Coverage Summary mette l’esecuzione in una tabella Markdown. Il file peggio coperto per primo, con una riga di totali, pronto da incollare in una pull request. Le colonne dei rami e di MC/DC compaiono solo quando qualcosa nell’esecuzione le ha misurate: una colonna di trattini si legge come copertura zero anziché come non misurata, che è l’opposto del vero.

Corretto

• L'identificatore di installazione poteva cambiare tra una sessione e l'altra — ed è da lì che si ricava l'impronta della licenza. Veniva ricalcolato a ogni chiamata e salvato senza che nulla attendesse la scrittura, quindi una seconda chiamata, o una finestra dell'editor chiusa poco dopo l'avvio, poteva generarne uno nuovo. Un identificatore che cambia è una chiave di attivazione che smette di corrispondere; gonfiava inoltre ogni cifra conteggiata per installazione. Ora viene stabilito una volta per sessione e salvato prima che qualcosa lo usi. Build 2.

Aggiunto

• Attribuzione dell’origine a livello di riga. Con più di un tracefile caricato, il suggerimento con il conteggio dei passaggi termina ora con Coperto da: e i report che hanno registrato un passaggio su quella riga — e un clic su una riga di tracefile nella vista Coverage illumina ora le righe che ha contribuito, in ogni editor aperto, come già illuminava i file che ha misurato. È l’unica domanda cui una run unita può rispondere e un singolo report no: due tracefile che misurano lo stesso file non concordano sulle sue righe, e finora l’unione appiattiva quel disaccordo senza mostrarlo mai. L’unione resta per file — il report più recente vince del tutto un file condiviso — quindi le origini per riga sono indicizzate prima. Contano solo le righe coperte: un report che ha registrato una riga a 0 non l’ha coperta.
• Il record TN: di lcov viene finalmente letto. Un tracefile che nomina la sua suite — TN:integration — appare come coverage.info (integration) ovunque venga nominata un’origine, e il nome sopravvive a un export di ritorno in lcov invece di essere scritto vuoto. La maggior parte degli strumenti scrive TN: vuoto e non cambia; quelli che lo riempiono sono proprio quelli i cui tracefile vengono uniti, e allora il nome è l’unica cosa che dice quale è quale.
• fuciniCoverage.lineHighlight colora le righe stesse. off | uncovered | heatmap, disattivato per impostazione predefinita: una tinta traslucida dietro ogni riga non coperta e parzialmente coperta, e in heatmap anche dietro ogni riga eseguita, tanto più calda quanto più spesso è stata eseguita. Un’impostazione a sé anziché un quarto valore di editorGutter.mode, perché le si vuole in coppie diverse: i vuoti colorati con il margine pulito, oppure barre senza colore dietro il codice. Traslucida perché sta sotto il testo, e colora i vuoti anziché le righe coperte, per la stessa ragione del margine.
• fuciniCoverage.overviewRuler decide da solo la striscia nella barra di scorrimento. follow (predefinito) fa quello che ha sempre fatto: una striscia dove il margine disegna una barra non coperta o parziale, e mai per la mappa di calore. uncovered la disegna anche con editorGutter.mode disattivato — una mappa dei vuoti del file lungo la barra di scorrimento e nulla accanto al codice. off mantiene le barre e toglie la striscia. Prima il righello era legato al margine, quindi quelle due combinazioni non c’erano.

Corretto

• Un tracefile che non si lascia analizzare ora dice come è stato letto. «…non è ben formato» lasciava indovinare se il file fosse mai stato riconosciuto come il formato che si crede — e un documento Cobertura rifiutato dal parser VectorCAST è un problema diverso da un documento davvero troncato. La notifica termina ora con È stato letto come cobertura. quando un parser ha rivendicato il file. Se non l’ha fatto nessuno, non si aggiunge nulla: «non è in un formato che questa estensione legge» lo dice già per intero.

Corretto

• L’avviso sui dati obsoleti nel suggerimento della barra di stato mostra di nuovo la sua icona dell’orologio, invece del testo $(history). L’avviso che dice che i numeri sottostanti descrivono una versione più vecchia dei file porta lo stesso segno $(history) della barra di stato stessa. Nella barra di stato quel segno è disegnato come icona dell’orologio, perché StatusBarItem.text sostituisce le icone da sé; il suggerimento è un MarkdownString, che deve aderirvi con supportThemeIcons e non lo ha mai fatto — così l’unica riga che spiega perché la copertura non è credibile iniziava con un pezzo di sintassi grezza. Ora il suggerimento vi aderisce.

Aggiunto

• Il gutter dell’editor può ora mostrare le righe non coperte, o una mappa di calore dei conteggi. Per impostazione predefinita mostra ancora solo i rilievi — barre MC/DC, triangoli «dall’ultima esecuzione», puntini sulle righe modificate — e la vista a colori di un intero file resta l’Annotated Source. fuciniCoverage.editorGutter.mode abilita di più: 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; heatmap aggiunge una tinta calda su ogni riga eseguita, più intensa quanto più spesso è stata eseguita. Choose Editor Gutter Mode... passa fra le tre dalla palette o dal menu della barra di stato. Il README dichiarava senz’altro «gutter nativi»; ora dice ciò che c’è davvero.
• Conteggi dei colpi in linea. fuciniCoverage.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.
• ${env:NAME}, ${config:section.key}, ${userHome} e ${workspaceFolderBasename} in ogni impostazione di percorso, accanto al ${workspaceFolder} che c’era già. 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.
• Una voce di coverageFile.paths può essere un URL http(s)://. L’artefatto viene scaricato nell’archivio dell’estensione a ogni caricamento e caricato da lì; la vista Coverage nomina l’URL, non il percorso della cache. Ogni scaricamento è condizionale (ETag / Last-Modified), così riscaricare un artefatto invariato non trasferisce nulla, e quando uno scaricamento fallisce viene caricata l’ultima copia scaricata e il motivo è nell’output. fuciniCoverage.remote.headers aggiunge intestazioni Name: value con le variabili espanse — Authorization: Bearer ${env:CI_TOKEN} tiene il token fuori da settings.json — e fuciniCoverage.remote.refreshMinutes riscarica a intervalli. Si aggiunge #lcov.info (o un altro nome di file) come frammento dell’URL quando l’URL stesso non termina con un nome di file, così il formato è noto.
• Il caricamento e Generate Full HTML Report mostrano l’avanzamento e si possono annullare. 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 (lettura, poi verifica delle sorgenti); uno più piccolo fa solo girare la barra di stato come prima. Annullare lascia caricata l’esecuzione precedente e lo dice. Il report HTML fa lo stesso per ogni pagina resa e scritta.
• Due motivi in più per ricaricare. Una voce assoluta di coverageFile.paths fuori dall’area di lavoro — un albero di build accanto al checkout, una radice di output Bazel — ora viene sondata anch’essa, così un file che compare lì dopo l’apertura della finestra viene caricato anziché non essere mai più guardato; l’osservatore vedeva solo l’area di lavoro. E fuciniCoverage.watch.reloadAfterTasks nomina attività (una label di tasks.json, o source: name come le mostra l’elenco Run Task, ad es. npm: test) la cui fine ricarica la copertura, che watch.enabled sia attivo o no — per le build che l’osservatore 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.
• Aree di lavoro multi-root. Ogni cartella di un’area di lavoro viene ora rilevata per conto proprio: coverageFile.defaultLocation, coverageFile.paths, pathRemap, ignore, watch.*, remote.*, badge.*, le directory dei report, gitDiff.*, problems.perLine, editorGutter.mode e hitCounts.inline vengono letti per cartella, così vale il .vscode/settings.json della cartella stessa o la sua voce nel .code-workspace; ${workspaceFolder} indica la cartella della voce stessa; i tracefile trovati in ogni cartella si uniscono in un’unica esecuzione, e la vista Coverage raggruppa i file per cartella. ${workspaceRoot} in una regola di pathRemap prova prima la cartella del tracefile, poi le altre. Tutto ciò che richiede una sola cartella — le finestre di dialogo dei file, l’output di report e badge, i metadati git, Run Tests with Coverage — prende quella dell’editor attivo, e con più cartelle e nessun editor l’esecuzione dei test chiede quale. Una cartella aggiunta all’area di lavoro o rimossa da essa ricarica la copertura da sola. Prima, dodici punti prendevano la prima cartella e una seconda radice riceveva la base sbagliata per tutto.
• L’esecuzione viene pubblicata nella vista Test Coverage di VS Code stesso. Con fuciniCoverage.testCoverage.publish (attivo per impostazione predefinita) ogni esecuzione caricata va anche al pannello nativo Test Coverage, alle sue percentuali per file nell’Explorer e all’interruttore «Show Inline Coverage» dell’editor stesso — righe, archi di ramo e funzioni, con i dettagli caricati su richiesta. 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.
• Quando i file non corrispondono viene suggerita una regola di rimappatura dei percorsi. 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 l’area di lavoro ha src/a.c. Quando un caricamento lascia file senza corrispondenza, l’estensione cerca i nomi dei file nell’area 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. Nulla viene scritto senza il clic.
• fuciniCoverage.ignore: file che non contano mai. I file vendorizzati, generati o di terze parti (vendor/**, **/*.generated.ts, build/**) vengono esclusi dall’esecuzione al caricamento, così la vista Coverage, la barra di stato, le soglie, i badge, il CodeLens, la cronologia e le esportazioni contano tutti senza di essi; il risultato del caricamento dice quanti sono stati lasciati fuori e l’output li nomina. I pattern corrispondono al percorso relativo all’area di lavoro e al percorso assoluto; un pattern senza / corrisponde a un nome di cartella o di file a qualsiasi profondità, come .gitignore. Per file interi — le righe dentro un file continuano a usare i marcatori di esclusione dello strumento stesso.
• Voci per riga nel pannello Problems, su richiesta. fuciniCoverage.problems.perLine (off, uncovered o uncoveredAndPartial; disattivata per impostazione predefinita) mette una diagnostica di tipo Information su ogni blocco contiguo di righe mai eseguite — una funzione morta di quaranta righe è una voce, non quaranta — e, nella seconda modalità, su ogni riga il cui arco di ramo non è mai stato preso. Solo per i documenti aperti, così un’esecuzione da duemila file non può inondare il pannello; le voci seguono le loro righe mentre il buffer viene modificato e spariscono alla chiusura del documento. La voce per file dietro problems.enabled è invariata.
• Un badge di copertura per il README. Generate Coverage Badge scrive un SVG in stile shields per l’esecuzione attiva nell’area di lavoro (fuciniCoverage.badge.outputPath, predefinito coverage-badge.svg), che un README incorpora con ![coverage](coverage-badge.svg) e nessun servizio in hosting. badge.metric sceglie righe, rami, MC/DC o il punteggio ponderato; il colore segue i livelli di colorScale; badge.autoUpdate lo riscrive dopo ogni caricamento. Il badge SVG che Export Coverage Report offriva già condivide ora lo stesso renderer.
• Non misurato contro non coperto. Un file che nessun test ha mai caricato non è affatto nel tracefile, così l’estensione l’ha sempre tenuto distinto da un file misurato con 0 colpi — e fuori dai numeri, che è esattamente il modo in cui un progetto con metà dei moduli senza test si legge «92%». Ora la distinzione si vede: aprire un file del genere mette not measured nella barra di stato, e fuciniCoverage.unmeasured.mode decide cos’altro succede. list aggiunge un gruppo Non misurati alla vista Coverage con ogni file dell’area di lavoro di un tipo che l’esecuzione ha misurato e che l’esecuzione non contiene, li conta nel risultato del caricamento, li contrassegna con ? nell’Explorer quando i badge sono attivi, e lascia che threshold.unmeasuredFiles faccia fallire Check Coverage Thresholds oltre un numero scelto. count va oltre: ogni file del genere entra nell’esecuzione come 0% — una riga non coperta per ogni riga di codice — così la barra di stato, le soglie, i badge, la cronologia, le esportazioni e la vista Test Coverage vedono tutti la cifra onesta; il file viene disegnato ovunque come non misurato, mai come «non corrisponde più alla sua copertura». unmeasured.exclude tiene fuori le intestazioni e simili (**/*.h, **/*.hpp, **/*.hh, **/*.inl, **/*.d.ts per impostazione predefinita). Disattivato per impostazione predefinita; lo stato della barra di stato è l’unica novità sempre attiva.
• La vista Copertura mostra cosa ha fatto la fusione. Dalla 0.2026.63 la riesecuzione di un modulo caricata sopra un’esecuzione dell’intero progetto sostituisce i numeri di quest’ultima per i file del modulo, e ogni riga nominava il report da cui proviene — ma una riga i cui numeri avevano prevalso su un report più vecchio era identica a una misurata da un solo report fra tanti, e niente diceva quanta parte di un report fosse stata sostituita. Ora il badge di tracefile di quella riga ha un contorno; ogni riga di tracefile sopra l’albero conta cosa ha fatto la fusione con i suoi file («42 file · 7 sostituiti da un report più recente», «7 file · sostituisce 7 in report più vecchi»); e un clic su una riga di tracefile evidenzia nell’albero completo i file che ha misurato, attenuando gli altri, finché non viene cliccata di nuovo. fuciniCoverage.coverageView.mergedMarks (attivo per impostazione predefinita) disattiva contorno ed evidenziazione; i conteggi restano.

Corretto

• A un utente Business o Enterprise ora viene chiesto il suo codice di invito, non il codice aziendale. Dal 2 settembre il server delle licenze rifiuta il codice aziendale condiviso per una postazione Business o Enterprise: una postazione occupata con quello non nominava nessuno, così ogni postazione di team è ora legata all’indirizzo a cui è stata invitata, e il codice che la attiva è il codice di invito FCI1… di quell’email. Il questionario etichettava ancora il campo «Codice aziendale», suggeriva di chiederlo al responsabile e mostrava un segnaposto FCB1… — mandando le persone a incollare proprio l’unico codice che non funziona più, e poi dicendo loro di inserire un codice aziendale quando lo lasciavano vuoto. Nei piani per team il campo ora recita «Codice di invito», il suggerimento dice da dove viene il codice e che il codice aziendale condiviso non attiva una postazione, il segnaposto mostra la forma FCI1… e il messaggio di validazione chiede il codice di invito. Pro chiede il suo codice di abbonamento con quel nome. Pro Plus è invariato: mantiene il codice condiviso di proposito. Tutte le 17 lingue dell’interfaccia hanno la nuova formulazione.

Corretto

• ${workspaceFolder} ora funziona in coverageFile.paths, come ha sempre fatto in coverageFile.defaultLocation. Le due impostazioni stanno una accanto all’altra e solo una documentava la variabile, così la gente la scriveva in entrambe — e una voce che inizia con ${ non è assoluta, quindi entrava nel glob di ricerca come letterale sotto la cartella base, non trovava nulla, e l’estensione diceva che non c’era copertura. Una voce del genere ora viene prima espansa, il che la rende un percorso assoluto, e semplicemente verificata. Nell’impostazione resta com’è scritta, non viene scritta una seconda volta in un’altra forma quando si sceglie lo stesso file, ed esce da sola dall’impostazione quando viene scaricata dalla vista Coverage.
• Un file di traccia configurato ma assente ora viene segnalato nell’output. Una voce con un percorso sbagliato falliva nell’unico modo che nulla segnalava: «nessuna copertura trovata», indistinguibile da un progetto che davvero non ne ha. [FUCINI_DISCOVERY] ora nomina ogni voce per cui non è stato trovato alcun file e il percorso in cui ha cercato, una volta per voce anziché a ogni ricaricamento; una voce con carattere jolly non viene segnalata, perché potrebbe attendere che una build scriva qualcosa.

Aggiunto

• Il CodeLens per funzione mostra ora rami, MC/DC e un punteggio composito, non solo righe e passaggi — «add: 92% coperto (12/13 righe, 52 passaggi, punteggio 88%, rami 3/4 (75%), MC/DC 2/3 (66%))». Ciascuno viene omesso per una data funzione quando il tracefile non ha nulla da riferire lì — una build in C puro senza dati sui rami, o una non strumentata con -fcoverage-mcdc — anziché mostrare un fuorviante 0/0; il punteggio, allo stesso modo, compare solo accanto ad almeno uno degli altri due, perché con le righe come unica metrica è per definizione lo stesso numero con cui il lens già comincia.
• Il suggerimento del badge di origine dice quanto tempo fa è stato scritto ciascun tracefile, non solo la sua marca temporale — «Misurato da module.info (2026-08-15 14:32 · 3 ore fa), in sostituzione di ciò che lcov.info (2026-08-01 09:10) ne diceva.» Arrotonda fino a «proprio ora»; oltre i 30 giorni si mostra solo la data assoluta.
• Un pareggio nell’mtime dei tracefile non passa più sotto silenzio. Due rapporti che arrivano nello stesso passo di build, o un file system la cui risoluzione dell’mtime è più grossolana di un secondo, possono riferire la marca temporale identica per file che misurano entrambi — prima il vincitore ricadeva sull’ordine di coverageFile.paths senza nulla sullo schermo a spiegarlo. Il canale di output ora lo dice: [FUCINI_MERGE_TIE] nomina entrambi i tracefile e quanti file condividono.
• «Show What Changed Since Last Run» nel menu … della riga di un file, non appena esiste un’esecuzione precedente con cui confrontare — la stessa differenza per file che Compare with Last Run già calcola, puntata sul solo file di cui si è chiesto anziché sull’intero albero. Un file su cui nulla si è mosso lo dice chiaramente invece di non offrire nulla.
• Comando Tune Colour Scale: provare colori e soglie di colorScale.* sulla vista Coverage dal vivo prima di adottarli. Ogni modifica va dritta nell’impostazione — la vista si ridisegna già a ogni cambio di colorScale/threshold, quindi scrivere il valore è l’anteprima — e un «Mantieni» o «Ripristina i valori originali» finale chiude il cerchio.
• Lacune di copertura per file nel pannello Problems, una voce per ogni file sorgente caricato sotto threshold.statement, dietro la nuova fuciniCoverage.problems.enabled (disattivata per impostazione predefinita — la soglia predefinita delle istruzioni è 100). Ogni voce riassume ciò che è scoperto («62% di righe coperte — 14 righe scoperte, 2 funzioni scoperte») e porta una correzione rapida che apre l’estensione di chat installata, qualunque sia (Copilot, Claude Code, …), con un prompt per scrivere un test per la lacuna — una diagnostica per riga inonderebbe Problems in una base di codice reale, quindi questa resta alla granularità del file, il livello su cui chi legge può davvero agire.

Corretto

• Il motivo di un file mancante, non corrispondente o verificato, nella vista Coverage, ora si può selezionare e copiare. Viveva solo nel suggerimento nativo title della riga, che — essendo quello del browser — non si può selezionare; chi voleva incollare il motivo esatto in una segnalazione di bug doveva ribatterlo a mano. Al passaggio del mouse ora compare lo stesso testo in un pannello vero, con stile, su cui si può trascinare come su qualsiasi altro contenuto della pagina. Il suggerimento di un file ordinario (solo il suo percorso) non cambia.
• Una funzione la cui lista di parametri si estende su più righe non viene più segnalata falsamente come spostata. detectMismatch consentiva alla riga registrata di una dichiarazione di discostarsi da dove il suo nome si trova davvero di al più due righe — abbastanza per il consueto disaccordo fra una riga di firma, una riga di tipo di ritorno e una graffa di apertura, ma non per una lista di parametri su più righe, che può allontanare le due quanto vuole. void LOG_Emit(...) — sette parametri, uno per riga — registrata alla sua graffa di apertura, riga 163, veniva segnalata come "LOG_Emit" is at line 3: la corrispondenza testuale più vicina, che per caso era il nome stesso della funzione citato nel commento di intestazione del file, lontanissimo dalla riga 163 e dalla dichiarazione vera alla riga 156. Il controllo ora accetta anche un nome trovato più indietro quando ogni riga fra esso e la riga registrata si legge come un’unica dichiarazione ininterrotta — nessuna riga vuota, nessuna riga che chiude l’istruzione o il blocco precedente — cosa che una lista di parametri fa sempre e una funzione davvero spostata quasi mai. Dove una discrepanza è ancora reale, la riga segnalata è ora la corrispondenza più vicina a quella registrata anziché sempre la prima trovata nel file.
• Il badge di origine non dice più «+N». Caricare il rapporto di un modulo sopra un’esecuzione più ampia marcava il badge del file con il nome del modulo più quanti altri tracefile lo coprivano — inteso come «questi tanti sono stati scavalcati», si leggeva come «questi rapporti concordano», e dall’albero non c’era modo di capire a quale degli n si riferisse davvero. Il badge ora nomina solo il tracefile i cui numeri sono sullo schermo; il suggerimento continua a spiegare cosa è stato scavalcato, e quando.
• Il badge di origine non spinge più fuori dal bordo del pannello il nome del file accanto a cui sta. La larghezza del badge era fissa (flex: none), così quando una riga restava senza spazio il nome del file assorbiva l’intero deficit ed era il primo a essere troncato, benché il badge sia il meno importante dei due. Il badge ora cede la propria larghezza prima che il nome del file perda un solo carattere; la percentuale e la barra, che già contano più del nome del file, non sono toccate.

Modificato

• La riesecuzione di un modulo sostituisce ciò che un’esecuzione più ampia ne diceva, invece di aggiungersi. Caricare un rapporto dell’intero progetto e poi, sopra, il rapporto di un singolo modulo sommava i loro conteggi di passaggi per ogni file che i due condividevano — rieseguire i soli test di quel modulo gonfiava numeri che un’esecuzione più ampia, ormai superata, aveva già riferito, anziché rinfrescarli. Il tracefile con l’mtime più recente su disco ora vince del tutto per ogni file che misura: istruzioni, rami, dichiarazioni e i riepiloghi per file (rami, MC/DC, funzioni, chiamate di funzione, oggetti e mutazioni) vengono tutti da quel solo rapporto, a prescindere da dove i due percorsi stiano in coverageFile.paths — la riesecuzione di un modulo vince perché è davvero più recente, non perché capita che si carichi per ultima. Un tracefile che per un file non riferisce alcuna istruzione — un’esportazione di codice oggetto di TRACE32, un rapporto di mutazione Stryker caricato accanto a uno vero — continua a contribuire solo il riepilogo che porta davvero, lasciando intatto il dettaglio di righe/rami di un rapporto precedente; quel caso non cambia. Questo elimina anche un difetto di vecchia data per cui un riepilogo MC/DC (o funzioni/chiamate di funzione/mutazioni) per file misurato da due esecuzioni aveva il denominatore sommato insieme al numeratore, sottostimando la percentuale vera. Il suggerimento del badge di origine ora dice «in sostituzione di ciò che _ ne diceva» anziché «sommati».

Corretto

• Un nome di file lungo nella vista Coverage ora viene troncato invece di traboccare. Allo span del nome nella riga mancava min-width: 0, l’unica dichiarazione che permette a overflow/text-overflow: ellipsis di un elemento flex di agire davvero — senza di essa un nome lungo teneva tutta la sua larghezza una volta che il pannello si restringeva abbastanza, passando sotto il badge di origine, la percentuale e la barra che lo seguono.

Aggiunto

• Ordinare la vista Coverage per punteggio, non solo per nome. Ogni riga porta già un punteggio WHM e una ripartizione per metrica; trovare il file peggiore in un albero grande voleva dire scorrere un elenco alfabetico in cerca di esso. Un menu a discesa accanto a Comprimi tutto / Espandi tutto offre ora Nome del file, Punteggio composito, Righe, Rami e MC/DC — ogni modalità tranne Nome del file intercala cartelle e file insieme, i peggiori per primi secondo la percentuale propria di quella metrica, così una cartella testata male si classifica esattamente come un file testato male anziché finire raggruppata lontano da esso. Un file senza dati per la metrica in vista (un formato che non riferisce mai i rami, per dire) finisce in fondo invece di essere letto come uno 0%. La scelta viene scritta nella nuova impostazione fuciniCoverage.coverageView.sortBy nel momento in cui è fatta, così sopravvive a un ricaricamento della finestra invece di ripartire sempre da Nome del file.

Corretto

• Una firma di funzione su più righe non viene più segnalata falsamente come «spostata». La fnMap di Istanbul dà a una funzione due riferimenti di riga — dove sta il suo nome e dove comincia il suo corpo — e il parser preferiva la riga del corpo per il controllo di discrepanza che poi cerca il nome nel testo sorgente. Per qualsiasi funzione la cui lista di parametri si estende su più di due righe (ordinaria in una base di codice a capo a 100 colonne), la riga vera del nome era troppo lontana da quella registrata, e il file si attenuava nella vista Coverage con un falso avviso «non corrisponde più alla sua copertura». Il parser ora preferisce la riga del nome stesso, che è ciò che il controllo di discrepanza ha sempre cercato.

Aggiunto

• Ogni riga dice quale tracefile l’ha misurata. Caricare il rapporto di un modulo sopra un’esecuzione dell’intero progetto sono gli stessi file misurati due volte, e l’albero non diceva quale rapporto stesse leggendo una riga. Con più di un tracefile caricato, ogni riga porta ora il nome del rapporto che l’ha misurata — l’ultimo caricato, quando sono stati più d’uno — con +1 per ciascuno degli altri e un suggerimento che li nomina. Un’unione somma i loro passaggi invece di far vincere uno, e il suggerimento lo dice. Con un solo tracefile non viene disegnato nulla, perché non ci sarebbe nulla da distinguere.

Modificato

• La pagina dell’estensione nomina ogni impostazione, con il suo vero valore predefinito. Venti impostazioni non avevano alcuna riga — la lingua, tre soglie, un peso e i quindici interruttori delle azioni rapide — e la riga della telemetria dichiarava un valore predefinito attivo mentre è disattivata da tempo. Un test confronta ora la pagina con il manifesto, valori predefiniti compresi.

Corretto

• Il ricontrollo delle sorgenti sotto files.watcherExclude, aggiunto nella versione precedente, obbedisce ora a staleWarning.enabled come il resto di quel controllo, e non a un nome di impostazione tutto suo.

Modificato

• Esplora risorse viene lasciato in pace. I badge di copertura accanto ai file sono disattivati per impostazione predefinita. Quella colonna è di chi la usa — VS Code ci mette la M e la U di git, e ci sta un solo badge — e la vista Copertura elenca gli stessi file con gli stessi numeri, in un posto che esiste per loro. explorerBadges.enabled li riporta invariati.

Corretto

• Anche una sorgente sotto files.watcherExclude viene ricontrollata. La corrispondenza dal vivo fra un file e la sua copertura è mossa dai salvataggi e da un osservatore del file system, muto per tutto ciò che è escluso — soprattutto le sorgenti generate sotto build/, dove un contrassegno scaduto è più difficile da notare. Quei file vengono ora sondati sullo stesso battito di due secondi dei tracefile e riletti solo quando si sono davvero mossi. Oltre i duecento, l’output lo dice invece di spendere il battito.

Aggiunto

• L’esecutore dei test si chiede una volta, non a ogni esecuzione. Un’area di lavoro con più esecutori riconosciuti — una configurazione jest e un go.mod, per dire — metteva il selettore davanti a ogni Run Tests with Coverage, chiedendo un tasto per una decisione già presa. La risposta ora viene ricordata per l’area di lavoro, e il messaggio lo dice. Forget the Test Runner rimette la domanda, e un esecutore ricordato che l’area di lavoro non ha più viene ignorato anziché eseguito.

Modificato

• La pagina dell’estensione nomina ogni comando. Quattordici dei trentaquattro erano usciti dalla sua tabella — documentati qui e nella guida, ma non nella pagina che si legge prima di installare. Ora ci sono tutti, e un test li tiene lì.

Corretto

• Annulla toglie di nuovo i puntini dalle righe modificate. Un buffer modificato dopo l’esecuzione mostra puntini grigi sulle righe riscritte, e la copertura si ritira da esse. Annullare quelle modifiche lasciava i puntini dov’erano: contava ogni cambiamento, compreso quello che rimetteva il testo. Ora si ricorda ciò che il buffer conteneva prima che qualcuno digitasse, e appena lo contiene di nuovo i puntini spariscono e i numeri tornano a valere.
• I numeri di versione vengono confrontati fra loro. Il manifesto, la voce in cima al changelog e l’etichetta di rilascio portano versione e build, tutte e tre scritte a mano, e hanno già divergito. La suite di test ora le confronta e verifica che le voci scendano dalla più recente, ciascuna con una data reale.

Modificato

• Un tracefile scaricato resta scaricato. Togliere un file dall’elenco nella vista Copertura durava esattamente quanto la finestra: senza nulla configurato la ricerca ripiega sui nomi noti e la mattina dopo ritrovava lcov.info, e l’unico modo di dire altrimenti era configurare un percorso per escluderne uno. La decisione ora viene ricordata per l’area di lavoro. La si annulla riscegliendo il file o nominandolo in coverageFile.paths — un file che l’impostazione nomina non viene mai trattenuto, quindi nulla può mancare senza che qualcuno l’abbia detto.

Corretto

• Ridisegno più rapido di un buffer modificato. L’elenco delle righe riscritte veniva ricalcolato da tutte le modifiche registrate a ogni ridisegno, così un file lungo modificato per tutto il pomeriggio pagava numero di righe per numero di modifiche per una risposta immutata dall’ultimo tasto premuto. Ora si calcola una volta per tasto premuto.

Modificato

• Un’esecuzione dei test ricorda il proprio tracefile, come una scelta a mano. Run Tests with Coverage caricava ciò che l’esecuzione aveva scritto e poi chiedeva se aggiungerlo a coverageFile.paths. Un file scelto a mano vi finisce da solo dalla 0.2026.56, e un’esecuzione dei test è lo stesso gesto per un’altra via, quindi ora lo scrive allo stesso modo. Un’unica impostazione, coverageFile.rememberPicks, governa entrambi; la riga del tracefile nella vista Copertura è dove l’uno e l’altro se ne vanno di nuovo.

Corretto

• I timer di sfondo si fermano quando si ferma l’estensione. L’osservatore del tracefile veniva liberato con la finestra, ma il sondaggio di due secondi dietro di esso e ogni ricontrollo di sorgente in sospeso sono timer ordinari, che nulla libera. Disattivare l’estensione, o ricaricare una finestra con l’estensione disattivata, li lasciava girare a leggere un’area di lavoro che all’estensione non riguardava più.

Aggiunto

• L'anteprima dal vivo dice cosa mostra. L'anteprima del pannello delle impostazioni inizia ora con Esecuzione: coverage/lcov.info · 12 file e, quando l'editor attivo mostra un file coperto dall'esecuzione, con File attivo: src/a.c e il verdetto proprio di quel file sotto quello dell'esecuzione. Segue l'editor e ogni caricamento, secondo ciò che il modulo contiene — modifiche non salvate incluse. Con il pannello in primo piano, un clic nella vista Copertura sposta l'anteprima su quel file invece di aprirlo.
• La finestra di scelta nomina ogni formato. Prima Tutti i formati di copertura, poi LCOV; JSON (llvm-cov, Istanbul/nyc, coverage.py, SimpleCov, Coveralls, gcov, xccov, Stryker); XML (Cobertura, JaCoCo, Clover, OpenCover, GNATcoverage, Bullseye, SonarQube, VectorCAST, TRACE32, EMMA, UCIS/UCDB, NCover, dotCover, PIT); profilo di copertura Go; listato gcov e Testwell CTC++ — e .lcov, .gcov, .txt e .coveragexml non sono più in grigio.

Modificato

• I suggerimenti della barra di stato indossano la scala di colori. Le barre delle metriche nei suggerimenti di esecuzione e di file prendono i tre colori di colorScale.*, graduati secondo la soglia propria di ogni metrica dove configurata e secondo i punti della scala altrimenti; le etichette del verdetto mantengono i colori di stato fissi.
• Bandiere disegnate nell'impostazione della lingua. Le emoji di bandiera di 0.2026.56 appaiono su Windows come due lettere nude. Il menu nomina ora ogni lingua con il proprio nome — Nederlands (nl) — con sotto una fila di piccole bandiere disegnate che selezionano nel menu.

Aggiunto

• Una scelta viene ricordata. Un file scelto con Pick Coverage File viveva solo nella finestra in cui era stato scelto. Ora finisce da solo in coverageFile.paths nelle impostazioni dello spazio di lavoro — relativo alla cartella base se sta sotto, assoluto altrimenti — così la finestra successiva lo carica e il watcher lo ricarica. coverageFile.rememberPicks (attivo per impostazione predefinita) mantiene il vecchio comportamento per chi lo vuole. Una voce assoluta in quell'impostazione ora indica un file ovunque sia.
• Tracefile nella vista Copertura. Sopra l'albero, una riga per ogni tracefile caricato con il suo numero di file e un pulsante di scaricamento che lo toglie dall'esecuzione e dalle impostazioni; un pulsante Scegli… accanto ne aggiunge uno. Scaricare l'ultimo tracefile svuota l'esecuzione.
• Bandiere nell'impostazione della lingua. Il menu della lingua nel pannello delle impostazioni mostrava codici nudi; ogni voce porta ora una bandiera e il nome della lingua in sé stessa — 🇳🇱 Nederlands (nl), 🇯🇵 日本語 (ja), 🌐 Automatico.

Corretto

• L'ultima riga di un file PHP non conta più come copertura oltre la fine. Xdebug e PCOV registrano il return implicito di fine file sulla riga dopo l'ultimo a capo, così php-code-coverage scrive un passaggio sulla «riga 252» di un file di 251 righe — e il controllo di discrepanza lo chiamava contraddizione su ogni file PHP con a capo finale. Una riga oltre un a capo finale è ora ammessa; un riferimento oltre quella, o oltre un file senza a capo finale, resta la contraddizione che era.

Aggiunto

• Una riga di prova in What Community Includes, nell'edizione Community. Quella build non ha mai avuto una prova, quindi il suo elenco ora inizia con Avvia una prova Pro di 14 giorni…, che apre la scheda Pro; l'attivazione della build Pro propone poi di togliere di mezzo la build Community. Community resta gratuito qualunque cosa si decida.

Aggiunto

• Show Worst-Covered Folders. La risposta a livello di cartella a Show Worst-Covered Files: ogni cartella ordinata per la copertura di tutto ciò che contiene, la peggiore prima, dallo stesso indice con cui vengono dipinti i badge dell'Esplora file; una scelta mostra la cartella nell'Esplora file. Nel menu della barra di stato con quickActions.worstCoveredFolders.

Aggiunto

• Il controllo delle soglie nel pannello Problemi. Con compliance.diagnostics attivo, ogni metrica threshold.* non raggiunta è un errore in Problemi, sul tracefile che l'ha mancata, aggiornato a ogni caricamento e da Check Coverage Thresholds, cancellato quando il controllo passa. Disattivato per impostazione predefinita, perché la soglia delle istruzioni fornita è 100.

Modificato

• La descrizione di watch.enabled non promette più una richiesta. Diceva ancora che al livello gratuito viene chiesto prima di ricaricare — vero fino a 0.2026.48, non da allora. Riscritta in tutte le 18 lingue.

Aggiunto

• Run Tests with Coverage. Riconosce vitest, jest, pytest, go, cargo, dotnet, maven, gradle, phpunit o ctest dalla radice dello spazio di lavoro, lo esegue con la copertura attiva in un'attività del terminale, carica ciò che ha scritto che i test siano passati o meno, e propone una volta di aggiungere quel percorso a coverageFile.paths perché da allora il caricamento lo faccia il watcher. Più runner vengono proposti come scelta; nessuno ti manda alle ricette.

Aggiunto

• La copertura segue il testo in un buffer modificato. Le modifiche a ogni buffer aperto dal caricamento dell'esecuzione vengono conservate, e ogni superficie che legge i numeri di riga dell'esecuzione — il conteggio al passaggio del mouse, la barra MC/DC, il triangolo «dall'ultima esecuzione», il CodeLens, Next Uncovered — legge attraverso di esse: un contrassegno si sposta con la sua riga e si ritira da una riga riscritta, dove un piccolo punto grigio dice perché. dirtyMarks.enabled disattiva i punti.

Aggiunto

• Dall'ultima esecuzione, nel gutter. Ogni riga eseguita nell'esecuzione precedente e non in questa porta un triangolo rosso nel gutter dell'editor, ogni riga che ha fatto il percorso inverso uno verde, ciascuno con una striscia nel righello panoramico e i conteggi al passaggio del mouse. Le righe invariate non mostrano nulla. sinceLastRun.enabled lo disattiva.

Modificato

• Il riferimento per «ultima esecuzione» sopravvive a un riavvio. Con history.enabled attivo, l'esecuzione più recente nella cronologia prende quel posto al primo caricamento di una finestra, così una build terminata prima dell'apertura della finestra mostra ancora ciò che ha cambiato — nel gutter e in Compare with Last Run.

Aggiunto

• Il verdetto su un file resta aggiornato dopo il caricamento. Un file veniva controllato rispetto alla sua copertura una volta, al caricamento del tracefile, e mai più: modificalo per un intero pomeriggio e i gutter continuavano a dipingere numeri su una versione che non esisteva più. Ora un salvataggio nell'editor ricontrolla subito quel file, e una modifica dall'esterno dell'editor — un git checkout, un formattatore, un generatore — lo ricontrolla da disco un istante dopo. Un file che arriva a contraddire la sua esecuzione riceve il contrassegno; un checkout che rimette la versione misurata lo toglie.
• La differenza esatta, al passaggio del mouse. Dove un file non corrisponde più alla sua copertura, la vista Copertura e il suggerimento dell'Esplora file dicono esattamente cosa lo ha dimostrato: la riga come si legge ora rispetto a ciò che il report aveva registrato quando il tracefile conservava il testo, la riga e un checksum fallito quando conservava un digest, copertura oltre la fine del file, una funzione che non è più dove il report la colloca. Lo stesso dettaglio va nel canale di output, una riga per file, dove porta Mostra quali sul risultato del caricamento.
• Un interruttore per i badge dell'Esplora file. explorerBadges.enabled (attivo per impostazione predefinita) nasconde il punteggio, ✓ e ⚠ accanto a ogni file coperto nell'Esplora file, e con essi il suggerimento per metrica. Gutter, barra di stato e vista Copertura non cambiano.

Modificato

• Ogni livello ricarica da solo quando il tracefile cambia. Dal 2026-09-02 il livello gratuito si fermava a una domanda nuova copertura rilevata — caricarla? mentre le licenze a pagamento ricaricavano in silenzio. Una build finisce, i numeri sono nuovi, e chi ha attivato il monitoraggio ha già risposto alla domanda — quindi la domanda è sparita su ogni livello, e con essa l'avviso che la spiegava.
• I caricamenti che il prodotto fa da solo non contano più nel limite giornaliero del livello gratuito. Una ricarica del watcher o la scoperta all'avvio non è un caricamento che qualcuno ha chiesto; contarli avrebbe esaurito la quota di un'installazione Community in una mattinata di test e poi lasciato una vecchia esecuzione sullo schermo senza nulla che lo dicesse. Il limite ora misura solo il comando e il selettore.
• Un timestamp cambiato da solo non segnala più un file. L'avviso N file cambiati da questa esecuzione derivava dalla mtime di ogni sorgente, e un git pull o un formattatore cambia ogni mtime senza alterare ciò che è stato misurato. È sparito, con il suo contrassegno nella barra di stato. Un file ora è detto cambiato solo quando il suo contenuto contraddice l'esecuzione, e la barra di stato, il risultato del caricamento e una nuova riga di output FUCINI_MISMATCH_001 leggono tutti da lì. staleWarning.enabled mantiene il nome e ora descrive esattamente il controllo del contenuto.
• Monitorare una cartella sotto files.watcherExclude viene detto nell'output. L'output della build è la prima cosa che si esclude dal watcher di VS Code, dopodiché solo il polling ogni 2 s nota una nuova esecuzione. Il canale di output ora indica la cartella e il glob all'avvio del watcher.

Aggiunto

• Un suggerimento al primo avvio per un workspace senza nulla da caricare. Il controllo è attivo per impostazione predefinita e il caricamento all'avvio è silenzioso, quindi un'installazione nuova in un progetto senza tracefile non diceva nulla. Il primo caricamento silenzioso che non trova nulla ora lo dice — una volta, per sempre — con le due cose che vale la pena fare: scegliere a mano un file di copertura, o aprire le ricette per produrne uno con la propria toolchain. Un caricamento avviato a mano mantiene il proprio messaggio.
• Tasti per Toggle Annotated Source e Load Coverage. Alt+A alterna la scheda attiva tra sorgente e vista annotata; Alt+Shift+R ricerca e ricarica la copertura (Ctrl+Alt+A / Ctrl+Alt+R su macOS). Riassegnabili come i due aggiunti in 0.2026.45.

Modificato

• I percorsi che non corrispondono a nulla nel workspace vengono contati a schermo. Un percorso del tracefile che non si risolve in alcun file del workspace si carica e non si illumina mai — il «ha funzionato ma non si vede nulla» più comune che esista — e finora l'unica traccia era una riga FUCINI_REMAP_001 nel canale di output, con la regola pathRemap che lo risolverebbe, non letta. Il risultato del caricamento ora li conta, con Quali? per i nomi e la regola suggerita, e Apri l'impostazione pathRemap per il posto in cui metterla.
• Il selettore di file del menu della barra di stato nomina i formati che legge. La sua descrizione elencava ancora i cinque formati della prima versione; ora ne dice venticinque, da lcov, Cobertura e JaCoCo a gcov, llvm-cov, TRACE32 e report di mutazione.

Modificato

• Entrambe le edizioni installate: due pulsanti invece di istruzioni. Con Pro e Community presenti insieme nessuna delle due può attivarsi — definiscono gli stessi comandi e le stesse viste — e il messaggio che lo diceva finiva con le indicazioni per la vista Estensioni. Entrambi i rimedi sono un comando ciascuno, quindi ora sono pulsanti: Tieni questo disinstalla l'altra edizione e propone il ricaricamento; Mostra entrambi in Estensioni apre la vista Estensioni esattamente su quei due. Se la disinstallazione fallisce, il ricaricamento viene comunque proposto — è il ricaricamento a decidere quale edizione è attiva.
• Un limite di utilizzo viene annunciato per intero una volta, poi solo nella barra di stato. La prima volta che si raggiunge un limite Community merita la risposta completa — i numeri, il piano, lo sblocco tramite telemetria, l'elenco di ciò che il livello include. La quinta volta, dieci minuti dopo, no. Nella stessa sessione, ulteriori raggiungimenti dello stesso limite mettono una riga di otto secondi nella barra di stato e non interrompono nulla. Inserire una chiave ricomincia da capo, perché una nuova licenza è un nuovo insieme di limiti.

Aggiunto

• Next / Previous Uncovered hanno i tasti. Sono i due comandi premuti più e più volte leggendo un file, e finora ogni pressione significava aprire la palette dei comandi e digitare il nome. Alt+N passa al successivo intervallo non coperto e Alt+P al precedente (Ctrl+Alt+N / Ctrl+Alt+P su macOS, dove Option digita caratteri). Entrambi valgono solo in un editor di testo attivo e si riassegnano in Keyboard Shortcuts come qualsiasi altra impostazione predefinita.

Aggiunto

• Cosa include Community, come un unico elenco. Il livello gratuito limita otto azioni e trattiene dodici funzionalità, e ognuna di quelle decisioni veniva applicata alla propria porta — quindi l'unico modo per conoscere la forma del livello era sbattere contro ogni muro uno alla volta, a metà lavoro. Un nuovo comando, What Community Includes, mostra tutto in una volta: ogni azione limitata con quanto del giorno o del mese è già stato usato, ogni funzionalità trattenuta per nome, e i due modi per rimuovere i limiti — un piano a pagamento o lo sblocco tramite telemetria.
• Offerto ovunque sorga la domanda. Una voce nel menu della barra di stato, un pulsante nel banner della licenza della vista Coverage e un pulsante sui due messaggi che un'installazione Community incontra davanti a un muro — limite di utilizzo raggiunto e questa azione non è inclusa. Le righe derivano dallo stesso insieme di diritti applicato dai controlli, quindi ciò che l'elenco dice è ciò che accadrà.

Modificato

• La modalità di controllo dice cosa farà sul livello gratuito. La voce nella barra di stato prometteva a tutti di «ricaricare automaticamente la copertura», e su Community è una promessa che il controllo non mantiene — si accorge e chiede. Ora la voce lo dice, e il comando si chiama Toggle Tracefile Watch, dato che «Toggle Watch» non diceva mai cosa venisse controllato. Il comportamento in sé è invariato.

Modificato

• Un tracefile che non si carica ora dice perché, e cosa provare. Ogni fallimento produceva la stessa notifica — «no coverage could be parsed. See output.» — con il motivo un canale più in là come codice e messaggio del parser. La notifica ora inizia dal file e classifica il rifiuto per ciò che era: non in un formato letto da questa estensione, non ben formato (la causa abituale è una build che lo stava ancora scrivendo), ben formato ma senza nulla registrato (l'esecuzione non ha eseguito codice strumentato) oppure impossibile da leggere. Le parole del parser stesso accompagnano, più file vengono contati, e il canale di output è offerto dietro un pulsante Mostra output invece di essere aperto a forza.
• I file che un tracefile elenca ma in cui non c'è nulla da misurare ora vengono contati a schermo. Un header di sole dichiarazioni è sempre rimasto fuori dalla vista Coverage invece di ottenere 100% su 0 di 0 — e il suo nome finiva nel canale di output, e da nessun'altra parte. Il risultato del caricamento ora dice N file senza nulla da strumentare non vengono mostrati, con un pulsante Quali? che apre il canale con i nomi.

Aggiunto

• NCover e JetBrains dotCover. Il Cobertura di Coverlet e OpenCover erano già letti qui, il che copre la maggior parte del nuovo lavoro .NET e nulla del tipo più vecchio. Una build che scrive ancora il Coverage.xml di NCover, o un team che misura con dotCover, aveva coverage su disco che questa estensione non poteva aprire. Nessuno dei due formati richiede un convertitore: entrambi portano già nomi di file e numeri di riga.
• Un punto NCover escluso viene scartato, non conteggiato come non eseguito. excluded="true" marca codice deliberatamente tolto dalla misurazione — un membro con [ExcludeFromCodeCoverage], o un filtro NCoverExplorer. Contarlo come non coperto farebbe sì che un'esclusione abbassi il numero che doveva correggere.
• dotCover richiede /ReportType=DetailedXML. L'altro suo report XML è un riepilogo senza alcun numero di riga; quel report viene riconosciuto e respinto indicando il flag che lo risolve, anziché fallire come formato sconosciuto. dotCover registra solo un sì o un no per istruzione, mai un conteggio di visite, quindi un'istruzione coperta arriva come un singolo hit.

Aggiunto

• Test di mutazione. La coverage dice che una riga è stata eseguita; un punteggio di mutazione dice che qualcosa è fallito quando quella riga è stata modificata. Una suite può eseguire ogni riga di un file senza rilevare nessuno dei difetti iniettati, e nessun numero di coverage lo dirà. PIT copre Java, Kotlin e Scala; Stryker copre JavaScript, TypeScript, C# e Scala.
• Non viene mai mediato con la coverage. Mescolare "questa riga è stata eseguita" con "qualcosa se n'è accorto quando l'ho cambiata" non risponde a nessuna delle due, quindi non ha alcun peso nel punteggio composito ed è controllato a parte tramite fuciniCoverage.threshold.mutation — 0 di default, perché un punteggio di mutazione è un obiettivo da alzare, non un'asticella da superare il primo giorno.
• Un mutante che non ha mai avuto un'esecuzione equa non conta in nessuna delle due metà. Il NON_VIABLE di PIT e i CompileError e Ignored di Stryker sono mutazioni che lo strumento non ha potuto creare; contarle come non rilevate penalizzerebbe una suite per un difetto che non le è mai stato offerto.

Aggiunto

• Il listato annotato .gcov. gcov --json-format è arrivato con GCC 9, e i cross-compilatori embedded sono spesso molto più vecchi; finora la risposta era installare prima lcov o gcovr. Il contatore di esecuzione ha cinque grafie e solo due sono numeri, e le annotazioni branch/call/function appartengono alla riga vicina anziché alla propria — tutto questo ora viene letto correttamente.
• Le annotazioni di chiamata diventano coverage per punto di chiamata. call N returned X% è esattamente la metrica delle chiamate di funzione aggiunta in 0.2025.38, che questo formato portava molto prima che qui ci fosse un posto dove metterla.

Aggiunto

• Coverage del codice oggetto — quanta parte del binario costruito è stata davvero eseguita. L'unica metrica qui che non si misura affatto dal sorgente: proviene da un debugger che osserva il flusso di istruzioni sul target reale, senza alcun effetto sonda sui tempi. È anche la risposta onesta a "questo copre l'assembly?" — l'assembly scritto a mano non viene mai instrumentato, e nessun'altra metrica qui può raggiungerlo.
• È un requisito, non un altro peso. La coverage del codice oggetto sussume la coverage delle istruzioni — il 100% qui implica il 100% là, ma non il contrario — quindi non ha alcun peso nel punteggio composito ed è invece controllata da una soglia, esattamente come richiede DO-178C livello A in aggiunta a MC/DC.
• 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; la scheda di conformità dice "312 byte mai eseguiti, con 100% di coverage delle righe" invece di seppellirlo come "94%". Il caso inverso — un intero binario dato per eseguito mentre il suo sorgente no — viene segnalato come una contraddizione, non come un punteggio basso.

Aggiunto

• Coverage delle chiamate di funzione — se ogni punto di chiamata è stato esercitato. Una domanda diversa dalla coverage delle funzioni: una funzione invocata una volta da uno dei suoi tre punti di chiamata è completa sotto Funzioni e qui completa per un terzo. VectorCAST, TRACE32 e Cantata lo riportavano tutti mentre questo modello non aveva dove mettere il numero.
• Questo completa VectorCAST e TRACE32. Le versioni precedenti rifiutavano deliberatamente di ripiegare questi dati nella coverage dei rami, perché gonfiare una percentuale di rami gonfia un numero che finisce in un audit. Entrambi i formati ora caricano ciò che hanno sempre inviato.

Modificato

• Il cancello di conformità e il punteggio ponderato ora conoscono sette metriche, non sei — due nuove impostazioni, fuciniCoverage.whmWeights.functionCalls e fuciniCoverage.threshold.functionCalls, con descrizioni in tutte le 17 lingue.

Modificato

• La coverage delle funzioni ora conta anche quando lo strumento non dice dove sono le funzioni. L'export func di TRACE32, gli elementi <method> autochiudenti di VectorCAST e il riepilogo method, % di EMMA indicano tutti e tre un conteggio di funzioni senza alcun posto dove mettere un CodeLens — tutti e tre venivano scartati in ingresso. Le dichiarazioni restano la fonte preferita dove esistono; il conteggio viene ora usato come ripiego dove non ce ne sono.

Aggiunto

• UCIS e UCDB XML — VHDL e Verilog, direttamente dal simulatore. Due documenti rispondono a questo nome, e un progetto ha quello scritto dal proprio simulatore, quindi entrambi vengono letti: la forma di scambio standard <UCIS> di Accellera, e l'ux:ucdb proprio di Aldec, che è ciò che acdb2xml produce realmente da Active-HDL e Riviera-PRO. La coverage di istruzioni e rami passa; la coverage toggle, FSM, asserzioni e funzionale non viene letta, e un documento che contiene solo quella lo segnala invece di caricarsi vuoto.
• Il VHDL open source qui non aveva già bisogno di nulla: il backend GCC di GHDL instrumenta con -Wc,-ftest-coverage -Wc,-fprofile-arcs, e il risultato passa attraverso gcov, gcovr o lcov. Questa versione è per i simulatori commerciali.

Aggiunto

• EMMA XML. Delphi non aveva alcun modo per entrare — niente lcov, niente Cobertura — e DelphiCodeCoverage scrive esattamente questo schema con -xml. È anche ciò che una buona parte di strumenti Java più datati emette ancora, quindi un solo parser apre un linguaggio e ripulisce un'eredità allo stesso tempo.
• Aggiungete -xmllines e il report guadagna veri conteggi di hit per riga, quindi gli indicatori funzionano; senza, c'è solo una percentuale cumulativa, che ottiene un riepilogo del file e nessun indicatore invece di un'ipotesi. Un nome di pacchetto puntato diventa una directory solo quando il file è un sorgente della famiglia Java; in un report Delphi lo stesso campo è un nome di unità, e anteporgli un prefisso inventerebbe una cartella che nessuno ha sul disco.

Aggiunto

• Esportazioni di coverage TRACE32. COVerage.EXPORT.ListModule scrive ciò che un debugger ha misurato da una trace on-target — non sorgente instrumentato, ma il flusso di istruzioni che il processore ha realmente eseguito, sul target reale, senza alcun effetto sonda sui tempi. Un'esportazione porta una metrica alla volta: stmt diventa coverage delle righe; dec/cond diventano coverage dei rami; mcdc diventa MC/DC. Caricate due esportazioni della stessa esecuzione e si uniscono per nome del modulo.
• Le esportazioni con coverage func, call o object venivano rifiutate per nome anziché caricate vuote, indicando quale metrica contiene il file — tutte e tre hanno ora una collocazione, rispettivamente in 0.2025.37, 0.2025.38 e 0.2025.39.

Aggiunto

• Listati di profilo di esecuzione Testwell CTC++. ctcpost trasforma MON.sym e MON.dat in un listato testuale a larghezza fissa — lo strumento che si contrappone a Bullseye nelle valutazioni embedded e di sicurezza europee, e quello che misura la coverage multicondizione. Letto per posizione di colonna anziché dividendo sugli spazi, perché una descrizione può a sua volta iniziare con una cifra.
• La multicondizione non è MC/DC, e non viene riportata come MC/DC. CTC++ conta combinazioni di condizioni; MC/DC chiede se è stato dimostrato che ciascuna condizione influenza indipendentemente l'esito. Mettere questi numeri dietro il cancello MC/DC darebbe a un revisore un numero sotto un nome che non significa quello, quindi qui sono coverage dei rami, che è ciò che sono.

Aggiunto

• VectorCAST XML. VectorCAST scrive un report Cobertura fino al doctype, e poi aggiunge attributi per ciò che il Cobertura comune non può dire. Ciò significava che questi file già si caricavano qui e sembravano completi — con mcdcpair-coverage scartato in silenzio all'ingresso, proprio per il pubblico che aveva comprato uno strumento appositamente per produrlo. Quei conteggi di coppie ora sopravvivono. Alimentano il cancello MC/DC, la percentuale e il punteggio composito.
• La coverage delle chiamate di funzione non viene deliberatamente approssimata. Ripiegarla nella coverage dei rami gonfierebbe un numero che finisce in un audit; attende che il modello abbia un nome per essa, cosa che avviene in 0.2025.38.

Modificato

• Il lettore Cobertura ora porta un dialetto: <coverage line-rate=…> è una famiglia, non un solo formato, e quale dialetto viene letto viaggia con il parsing invece di essere indovinato elemento per elemento.

Aggiunto

• GNATcoverage XML — finalmente Ada. I team avionici DO-178C e ferroviari EN 50128 sono esattamente il pubblico per cui sono stati creati il punteggio ponderato per la sicurezza e il supporto MC/DC di questo prodotto, e finora non potevano caricare nulla qui, a meno che il loro gnatcov non fosse abbastanza recente da emettere anche Cobertura, che scarta tutto ciò che sta sotto la riga. gnatcov coverage --annotate=xml scrive una directory e non un file: carica i file *.xml per sorgente — aprire index.xml ti dice dov’è davvero la copertura invece di fallire in modo oscuro. Una riga parzialmente coperta resta una riga coperta con una decisione non coperta: la carenza compare nella copertura di ramo e MC/DC, dove le compete. Le regioni di esenzione diventano righe escluse, un obbligo indeterminato conta come non coperto anziché coperto e, con --level=stmt+mcdc, l’MC/DC viene contato per condizione e alimenta la soglia e il punteggio composito.
• BullseyeCoverage e Visual Studio .coveragexml. Bullseye è lo strumento commerciale C/C++ che i team embedded e safety-critical possiedono davvero; esegui il suo covxml e carica il risultato. La sua metrica principale è la copertura condizione/decisione e non quella di riga, e qui le due restano separate — inoltre una sonda a esito singolo viene valutata su uno e non su due, così uno switch testato per intero non risulta coperto a metà. Il .coveragexml di Visual Studio completa .NET per i team su MSTest e vstest anziché Coverlet: converti prima il .coverage binario con dotnet-coverage convert. Le righe parzialmente coperte sopravvivono al passaggio in entrambi i casi.
• Copertura generica SonarQube — e una risposta netta su Xcode. Quattro attributi su due elementi, e conta perché quasi ogni strumento che non sa emettere uno degli altri formati sa emettere questo: un progetto il cui strumento di copertura questa estensione non ha mai sentito nominare ha finalmente una via d’ingresso. È anche ciò che scrive xcresultparser, ed è così che i progetti Swift e Objective-C arrivano qui: .xcresult non ha un parser, e la documentazione ora dice perché invece di lasciartelo indovinare — xccov riporta percentuali, non dati per riga, e l’archivio per riga si legge solo un file alla volta, in un documento che non nomina mai il file che descrive.
• I tracefile gzip si caricano così come sono. gcov --json-format scrive .gcov.json.gz per impostazione predefinita, quindi il formato annunciato dalla documentazione era quello che la maggior parte delle persone non riusciva a caricare. Il riconoscimento avviene dai magic byte del file anziché dal nome, così un report compresso che ha perso il suo .gz funziona lo stesso — e qualsiasi formato supportato può ora arrivare compresso, non solo quello di gcov.
• Swift e Objective-C, dal rapporto di Xcode. xcrun xccov view --report --json è l'unico documento di copertura che una build iOS o macOS produce senza strumenti aggiuntivi. Ottieni percentuali per file, conteggi di esecuzione per funzione e CodeLens. Non contiene dati per riga, e Studio non se li inventa, quindi i margini restano vuoti per questo formato: un margine inventato è indistinguibile da uno misurato. Per la copertura Swift riga per riga usa llvm-cov export -format=lcov o slather, che già funzionavano.
• Coveralls JSON — scritto dai reporter di Elixir, Ruby, Python, Rust, Go e JavaScript. È per riga, quindi i margini funzionano.
• Giorni attivi, blocchi di soglia e la licenza a cui appartiene un riepilogo — tre aggiunte al riepilogo mensile di utilizzo, per le installazioni che hanno attivato la telemetria.

Rimosso

• Il nome del computer non viene più inviato. hostname era nella base della telemetria fin dall'inizio — al di fuori di ogni controllo, inviato da chiunque avesse la telemetria attiva. Il nome di un computer è molto spesso il nome di una persona, un numero di scrivania o il progetto di un cliente, e non rispondeva ad alcuna domanda sull'utilizzo cui il sistema operativo non rispondesse meglio. Un'installazione è ora identificata solo dal suo id di installazione casuale. Con questo, nulla che nomini te o la tua macchina la lascia: né il nome del computer, né il nome utente del sistema, né la home, né le interfacce di rete, né i percorsi dei file, né il nome della cartella del progetto, né un'etichetta di account connesso. Restano il sistema operativo, la sua versione e la sua architettura — che tipo di macchina, non quale.
• La telemetria viene ora eliminata entro 90 giorni al più tardi, mentre l'informativa diceva soltanto che era «conservata finché è utile», che non è affatto un termine.

Modificato

• Una licenza a pagamento ora ricarica la copertura da sola. Monitorare un tracefile ha sempre significato sentirsi chiedere «nuova copertura rilevata, caricarla?» dopo ogni build, su ogni livello: una domanda con una sola risposta sensata, posta più volte all'ora. Quella richiesta è ora il comportamento del livello Community gratuito; una licenza a pagamento carica e basta. Community mantiene il monitoraggio, il rilevamento e la richiesta che ha sempre avuto.
• Un file che non corrisponde più viene indicato, con il controllo che lo ha dimostrato, su una licenza a pagamento. Il rilevamento non è limitato e non lo sarà: dire a qualcuno che la sua copertura non descrive più il suo file non è una cosa da vendergli. Community riceve comunque il rilievo, e la riga resta attenuata. Una licenza a pagamento aggiunge l'indicazione: il segno, il contrassegno in Esplora risorse e la riga, la funzione o il checksum dietro di esso.
• La telemetria invia meno e dice a chi appartiene. Il riepilogo mensile non contiene più percorsi di file, il nome della cartella del tuo progetto o un'etichetta di account. Lo scambio funzionalità-per-telemetria ora chiede un indirizzo e-mail, così chi lo ha accettato può sapere cosa invia la sua installazione e farlo cancellare su richiesta.
• Corrette tre descrizioni di impostazioni. watch.enabled, staleWarning.enabled e telemetry.enabled si erano allontanate da ciò che fa il codice — telemetry.enabled più di tutte: descriveva un invio ben più ampio di quello reale.

Corretto

• Il selettore di file non nasconde più i formati che legge. Pick Coverage File filtrava su info, json e xml, così il coverage.out di Go e il .gcov.json.gz di gcov — entrambi formati che questa estensione legge — risultavano disattivati proprio nella finestra che ti chiede di sceglierne uno.
• Un'installazione Community ordinaria non invia più una pagina del proprio codice sorgente. Il controllo che proteggeva il campione di sorgente annotato trattava ogni installazione Community come se avesse accettato lo scambio di telemetria, non solo quelle che l'avevano fatto davvero.
• Un avviso per caricamento invece di due — un file che non corrisponde più alla sua copertura è quasi sempre stato modificato anche dopo l'esecuzione, e ciascuna cosa veniva segnalata separatamente.
• Una disinstallazione non riporta più il nome utente del sistema operativo e la cartella home di qualcuno la cui licenza lo vieta.

Aggiunto

• Profili di copertura Go. go test -coverprofile è l'unico output di copertura prodotto dalla toolchain standard di Go — non c'è un lcov su cui ripiegare come per Rust, Dart ed Elixir — quindi un progetto Go non aveva nulla che questa estensione potesse leggere. Un profilo registra blocchi anziché righe, e ogni riga coperta da un blocco assume il suo conteggio, parentesi di chiusura compresa, esattamente come le evidenzia go tool cover -html. coverage.out entra tra i nomi cercati per impostazione predefinita, così un progetto Go senza configurazione trova il suo profilo come un progetto C trova lcov.info.
• Clover XML e OpenCover XML. Clover è ciò che i progetti PHP hanno davvero: php-code-coverage può emettere Cobertura, ma Clover è il suo formato predefinito e quello che configura quasi ogni phpunit.xml — la copertura PHP era dunque illeggibile qui mentre un parser Cobertura attendeva un output che quasi nessuno genera. Il reporter clover di Istanbul scrive lo stesso documento, quindi anche un progetto Jest così configurato è coperto. OpenCover è la controparte .NET: C# e VB.NET arrivavano già come Cobertura, che appiattisce una decisione nella stringa condition-coverage="50% (1/2)", così quale ramo fosse stato eseguito spariva prima che un parser lo vedesse. OpenCover conserva un conteggio per ramo: la differenza fra sapere che metà di una diramazione è coperta e sapere quale metà.
• JSON di coverage.py e di gcov/gcovr. Le esportazioni Cobertura e lcov di coverage.py devono dichiarare una riga # pragma: no cover o coperta o mancante, non avendo una parola per «esclusa deliberatamente» — e questa estensione ce l'ha: lo stesso contrassegno che pongono i suoi marcatori LCOV_EXCL. I pragma di un progetto Python significano quindi qui ciò che significano nel report di coverage.py stesso. La copertura GCC, dal canto suo, arrivava solo dopo un passaggio per lcov o gcovr -x: un secondo strumento per convertire dati che GCC aveva già prodotto. gcov --json-format --stdout e gcovr --json emettono documenti quasi identici, e un solo parser ora li legge entrambi.

Corretto

• I commenti vengono letti nel linguaggio in cui è scritto il file. Lo scanner delle righe non di codice era stato scritto per il C e applicato a ogni file, il che era corretto finché ogni formato letto da questa estensione descriveva un linguaggio della famiglia C. Non lo è più: uno scanner C che incontra # don't vede l'apostrofo aprire una stringa, non la vede mai chiudersi e conta la riga di commento come codice — un numero silenziosamente un po' sbagliato, senza nulla che lo segnali. Ora è # per Python, Ruby, shell, Perl, R, Elixir e Julia; tutte e tre le forme per PHP, che le accetta tutte; e // con /* */ per tutto il resto, che resta il valore predefinito per un'estensione sconosciuta: #define è codice, ed escluderlo sarebbe sbagliato nella direzione opposta.

Aggiunto

• Ogni impostazione fuciniCoverage.* ha ora un posto in quel pannello, non solo le tredici di conformità. Tutte e cinquantacinque sono raggruppate nelle stesse sezioni, nello stesso ordine, del riferimento delle impostazioni pubblicato, così la pagina da cui configuri e quella che leggi concordano su dove vive un'impostazione. Un campo di ricerca filtra per nome, chiave o descrizione; un elenco di collegamenti sposta tra le sezioni. Il modulo è derivato in fase di esecuzione dal manifesto incluso nell'estensione stessa — tipi, valori predefiniti, limiti, enumerazioni e ogni parola di testo — quindi nulla di un'impostazione è scritto due volte e il pannello non può divergere dall'estensione che modifica.
• Le descrizioni seguono la lingua che hai fissato. VS Code risolve la localizzazione di un manifesto dalla lingua di visualizzazione dell'editor al caricamento dell'estensione e non offre alcun modo di sovrascriverla per singola estensione: impostare fuciniCoverage.language su tedesco in un editor in inglese traduceva quindi tutto tranne le impostazioni. Poiché il pannello legge e risolve quei file da sé, è l'unico punto che può rispettare quella scelta.
• I controlli che uno schema JSON non può chiedere. Nulla in uno schema di impostazioni segnala che una stringa è un percorso, quindi l'interfaccia nativa non può offrire un selettore; le tre impostazioni che contengono una cartella hanno ora un pulsante Sfoglia…. coverageFile.paths e pathRemap ottengono veri editor di elenco invece di una casella JSON grezza, e ogni colore colorScale un campione accanto al suo valore esadecimale.

Modificato

• Il salvataggio scrive ciò che hai cambiato, e nient'altro. Con tredici impostazioni contava poco che Salva le scrivesse tutte e tredici; con cinquantacinque significherebbe che una singola modifica imprime l'intero spazio dei nomi in un settings.json che aveva due righe. Vengono scritte solo le impostazioni il cui valore è davvero cambiato, e un valore uguale al predefinito rimuove l'override invece di ripetere ciò che l'estensione già fornisce.
• La chiave di licenza va sempre nelle tue impostazioni utente, e la riga lo dice. license.key è dichiarata con ambito applicazione, il che significa che VS Code la legge solo da lì: scriverla in un'area di lavoro è un salvataggio che sembra riuscito e non cambia nulla. Ripristina ora cancella tutte e cinquantacinque le chiavi nell'ambito scelto anziché tredici, perciò chiede prima. E una modifica fatta fuori dal pannello non ti costa più il tuo posto: la pagina confronta prima di ridisegnare, così Salva non riporta più cinquantacinque righe in cima.

Aggiunto

• La modalità di conformità, i sette criteri di soglia e i sei pesi del punteggio composito hanno ora un unico editor. Nell'interfaccia delle impostazioni sono tredici righe slegate, e nella pratica una sola decisione: una soglia resta inerte finché la modalità in vigore non la consulta, e un peso resta inerte finché a decidere non è il criterio ponderato. Fucini Coverage: Configure Coverage Compliance & Thresholds..., sul pulsante a ingranaggio nella barra del titolo della vista Coverage, riunisce i tre, spiega ogni modalità dove la modalità si sceglie, e nomina i modi in cui un criterio può essere configurato per non verificare nulla — una modalità rigorosa senza alcuna soglia per metrica, una modalità ponderata con soglia 0, pesi tutti a 0 — come avvisi, mentre li stai guardando.
• Mostra il verdetto in anteprima e scrive tramite VS Code. Il COMPLIANT / NON-COMPLIANT che il modulo non salvato produrrebbe sull'esecuzione caricata è calcolato dal motore di conformità dell'estensione stessa e non da una seconda copia delle regole: un'anteprima che può contraddire il criterio è peggio di nessuna anteprima. Le modifiche passano per la normale API di configurazione verso settings.json — utente o area di lavoro, a tua scelta — così VS Code formatta il file e ne conserva i commenti; una modifica fatta a mano o in un'altra finestra rientra nel modulo aperto, che ci sia o meno un'esecuzione caricata. Non serve alcuna licenza: Community ottiene lo stesso editor di Pro.

Corretto

• Il pulsante della notifica di aggiornamento riportava Download && Install. La e commerciale raddoppiata è l'escape dei mnemonici, corretta nei titoli di package.json e nelle finestre modali — ma i pulsanti di azione di una notifica prendono la propria etichetta come testo semplice, quindi entrambi i caratteri venivano stampati esattamente come scritti, in tutte le 17 lingue, a chiunque ricevesse la proposta di aggiornamento.

Modificato

• La telemetria è disattivata per impostazione predefinita. Veniva distribuita attiva, con la motivazione che il periodo di valutazione avesse bisogno di quei dati. Quella motivazione ha smesso di valere nel momento in cui il livello Community ha reso l'attivazione della telemetria ciò che sblocca gratuitamente tutte le funzionalità Pro: uno scambio significa qualcosa solo se lo fa la persona, e uno scambio che nessuno ha scelto non è uno scambio. Non viene inviato nulla finché non la attivi, e Community continua comunque a funzionare con il suo set di funzionalità standard.
• L'impostazione della telemetria dice a cosa serve e per il resto rimanda. La sua descrizione elencava prima ogni campo trasportato da un ping, il che significava due copie di quell'elenco — una nell'impostazione, una nell'informativa sulla privacy — che dovevano restare identiche per sempre e non lo erano. Ora dice cosa ottieni attivandola e rimanda all'informativa sulla privacy per l'elenco dei campi: un solo elenco da tenere veritiero invece di due.
• Installare questa versione riapre la tua finestra di valutazione, una volta. Chi aveva già esaurito la prova riceve 14 giorni nuovi, perché questa versione cambia le condizioni in cui aveva valutato: una prova trascorsa con la telemetria attiva per impostazione predefinita non era una prova del prodotto ora offerto. È legata deliberatamente a un token monouso anziché alla versione: azzerarla a ogni versione significherebbe che la prova non finisce mai per chi si tiene aggiornato, il che non è una prova ma una licenza senza prezzo con qualche passaggio in più. Il token viene consumato alla prima attivazione e le regole ordinarie riprendono. Una licenza a pagamento non è toccata, poiché la verifica della chiave ritorna prima ancora che la prova venga consultata, e Community non è interessato perché quell'edizione non ha una prova da riaprire.
• Una chiave di licenza non costa più un questionario. Gli avvisi di attivazione, l'impostazione della chiave di licenza e la finestra di fine prova presentavano tutti la chiave come qualcosa emesso in cambio di risposte a domande. Non è così: la chiave viene emessa automaticamente su richiesta, e il questionario di feedback è facoltativo e del tutto separato.

Corretto

• Tre punti promettevano ancora una prova «fino al 2026-12-31». Una data simile non è mai esistita nel prodotto: la prova dura 14 giorni, contati per installazione dal primo utilizzo. Due versioni precedenti avevano intercettato questa affermazione nelle descrizioni delle impostazioni e nel README; è sopravvissuta nel riquadro di valutazione di questa stessa pagina, nella Guida utente e nel README degli strumenti di licenza. La Guida utente era la peggiore delle tre: affermava che la finestra valeva «per ogni installazione, in tutto il mondo, in una volta sola (non un conto alla rovescia per installazione)», l'esatto contrario, e che il rendering della copertura viene sospeso al termine della prova quando in realtà l'estensione passa al livello gratuito Community.
• Le e-mail di notifica della telemetria partivano dal dominio sbagliato. L'intestazione From: era una casella su fucini.consulting mentre il server che le invia è fucini.software: proprio l'allineamento di cui avverte il commento dell'impostazione stessa, e un modo sicuro per far filtrare la posta come spam o farla rifiutare del tutto.

Modificato

• Un file che il report nomina ma che non è sul disco viene mostrato dove gli spetta, in grigio, e dice perché. 0.2025.25 ha smesso di inventare posizioni per questi file, e faceva bene, ma lasciava loro un percorso relativo che non è affatto una posizione — così l'albero continuava a farne un progetto dal primo segmento, e le tre sorgenti cancellate di un sottomodulo finivano in un app fantasma accanto al sottomodulo da cui venivano. La discrepanza era visibile, ed era il punto, ma era visibile nel posto sbagliato e non diceva nulla su cosa non andasse.
• Ora compare nel progetto da cui è stato misurato, nella cartella in cui lo colloca il report — disegnato nel grigio medio del tema e in corsivo anziché nel colore di primo piano abituale. Al passaggio del mouse mostra il percorso che avrebbe avuto e spiega che lì non c'è nulla — con ogni probabilità rinominato o eliminato dopo la generazione del report — e che i suoi numeri contano ancora. Nulla viene scartato e nessun totale si sposta: la riga è ciò che il report dice di sé, e il grigio è ciò che le impedisce di sembrare una riga che si apre.
• La supposizione resta dentro la vista. Il percorso registrato del file è ancora esattamente quello che diceva il report, perché tutto il resto è indicizzato su di esso — l'arricchimento del report esterno vi si confronta, la telemetria lo rende relativo, la vista annotata lo apre — e dare loro una posizione presunta scambierebbe il noto con l'inventato. Solo l'albero unisce i due, e solo per un percorso che non nomina una posizione propria: un percorso assoluto che semplicemente non esiste conserva quanto diceva il report ed è ingrigito dov'è.

Corretto

• La copertura di un sottomodulo finisce dove il sottomodulo si trova davvero, e le sue righe si aprono. Un sottomodulo git costruisce il proprio report accanto al proprio albero, e gcovr vi scrive <source>.</source> — "la cartella in cui si trova questo file" — con nomi come app/Application.cpp sotto. Nulla ancorava quel . da nessuna parte: i percorsi venivano risolti una sola volta, dopo la fusione, quando l'esecuzione non sapeva più da quale input venisse ciascun file, così l'unica base rimasta era la radice dell'area di lavoro. Provare <workspace>/app/Application.cpp non trovava nulla, ogni percorso restava relativo, e la vista Copertura li disegnava come un progetto chiamato app — dal primo segmento di un percorso che non è mai stato una posizione — le cui righe copiavano e aprivano dove nessun file stava.
• I percorsi ora si risolvono per file di trace, prima della fusione. Un sourceRoot relativo viene ancorato alla cartella in cui si trova il suo file di trace, così . accanto al coverage.xml di un sottomodulo indica quel sottomodulo. Se ciò non trova i sorgenti, la ricerca risale verso l'alto dal file di trace — la disposizione CMake abituale scrive la copertura diversi livelli dentro build/, e quale delle due forme usi un progetto non è scritto da nessuna parte nel report, quindi risponde il filesystem anziché la configurazione. La risalita si ferma alla radice dell'area di lavoro: andare oltre lascerebbe un semplice src/main.c risolversi in un checkout vicino con la stessa disposizione, una risposta sbagliata che sembra giusta. Un percorso già assoluto e presente resta com'era, quindi le normali esecuzioni lcov non cambiano.
• Un sottomodulo resta un progetto a sé nella vista Copertura. I file che ora si risolvono dentro l'area di lavoro sarebbero altrimenti confluiti nel suo albero — le cartelle del sottomodulo intrecciate con quelle del genitore e i suoi numeri sommati al totale del genitore come se una sola base di codice fosse stata misurata due volte. Ogni file registra la radice da cui è stato misurato e la vista raggruppa in base a quella, così un sottomodulo mantiene intestazione e totali propri anche se sta dentro la cartella aperta. Un'esecuzione con percorsi già assoluti non ha tale radice e si raggruppa esattamente come prima.
• Un file che il report nomina ma che non c'è più viene ancora segnalato come mancante. Non gli si assegna un percorso plausibile in cui non si trova: un report che nomina file ormai cancellati è un report obsoleto, e disegnarli in posizioni inventate lo nasconderebbe. Ciascuno è nominato nel canale di output sotto FUCINI_REMAP_001, con il percorso che avrebbe avuto.

Modificato

• Una postazione che sparisce ora dice perché. Ogni revoca mostrava la stessa riga — la tua postazione in questo piano non è più attiva — che si legge come un'accusa rivolta alla persona sbagliata. Un abbonamento per team ridotto sotto le postazioni in uso ora libera l'eccedenza dopo un periodo di tolleranza, e chi perde una postazione non ha fatto altro che essere quello che non la usava da più tempo. Dove il server delle licenze ha qualcosa di utile da dire, l'estensione lo dice: una postazione liberata per rientrare in un abbonamento ridotto spiega esattamente questo e indica chi gestisce l'abbonamento, con Richiedi nuova chiave ancora offerto — perché la via del ritorno è reale: il gruppo ha posto nel momento in cui quella persona ne libera una.
• Un abbonamento terminato non offre alcun pulsante. Da un abbonamento scaduto non si può emettere una nuova chiave, quindi l'unica azione di quella notifica poteva soltanto fallire — e si legge come un'estensione rotta anziché come un abbonamento finito. Ora dice cosa è successo e si ferma lì. Qualsiasi motivo che questa build non riconosce mantiene la formulazione generale: il server delle licenze viene distribuito di continuo, un'estensione installata no, quindi incontrare un motivo sconosciuto è il caso ordinario e non quello limite — non mostra mai un identificatore grezzo e non tace mai. Entrambi i nuovi messaggi sono tradotti in tutte e diciassette le lingue.

Aggiunto

• L'esecuzione può finalmente uscire, in sei formati in più. Finora le uscite erano due: Fucini JSON, che non legge nulla al di fuori dell'estensione, e un report HTML, che non legge nulla in modo automatico. Export Coverage Report... apre un selettore di formato e scrive l'esecuzione attiva come CSV per file (coperto/totale/percentuale per righe, rami, funzioni, MC/DC, regioni e istanziazioni, i peggiori per primi, con una riga TOTAL), come CSV per funzione (numero di esecuzioni, se è stata eseguita, rami non coperti al suo interno, coppie MC/DC), come riepilogo Markdown da incollare in una pull request, come file di trace LCOV, XML Cobertura, SARIF, o come badge SVG autonomo per un README. Si trova nella palette dei comandi, nella barra del titolo della vista Covered Files accanto a Generate Full HTML Report, e nel menu rapido della barra di stato non appena quickActions.exportReport è attivo.
• Ora è un convertitore, non solo un visualizzatore. L'estensione legge già lcov, llvm-cov JSON, Cobertura, JaCoCo, Istanbul/nyc e SimpleCov; con gli scrittori LCOV e Cobertura sa fare anche il percorso inverso. Caricate un report JaCoCo, o più report uniti in un'unica esecuzione, ed emettete l'unico file di trace che genhtml, Codecov, Coveralls e SonarQube accettano tutti — oppure l'XML che Jenkins, GitLab e Azure DevOps acquisiscono nativamente. Entrambi ripassano dai parser dell'estensione stessa, e gli intervalli di righe vengono espansi riga per riga perché gli LF/LH scritti coincidano con la percentuale a schermo invece di approssimarla.
• Ogni scrittore dichiara cosa scarta. Tutti tranne i CSV perdono informazioni, e in silenzio: MC/DC, regioni di codice e istanziazioni C++ non hanno rappresentazione in LCOV, Cobertura o SARIF, e Cobertura registra quante condizioni di una riga erano coperte, non quale. Fucini JSON e i due CSV restano i formati che portano tutto ciò che è stato misurato. Nei CSV una metrica che l'esecuzione non possiede lascia le sue celle vuote anziché a zero — una cella vuota dice "questo strumento non ha riportato dati sui rami", uno 0 direbbe "nessun ramo è stato raggiunto", e in seguito un foglio di calcolo non sa più distinguerli. Tutto ciò che un foglio di calcolo eseguirebbe come formula — un campo che inizia con =, +, - o @, cioè qualsiasi percorso con scope npm — viene virgolettato e disinnescato prima della scrittura.
• SARIF annota il diff; il badge non chiede nulla alla rete. Gli intervalli non coperti sono segnalati al livello note, non warning: il codice non coperto dice qualcosa sulla suite di test, e il code scanning tratta un warning come qualcosa che dovrebbe bloccare — il cancello che blocca resta Check Coverage Thresholds. Il badge viene disegnato qui anziché richiesto a shields.io, quindi funziona anche in un repository isolato o on-premises, e prende il colore dalla stessa colorScale dei margini e della barra di stato. Nell'edizione Community gratuita il selettore si apre ed entrambi i CSV funzionano, con un tetto di 20 esportazioni al giorno come Export Fucini JSON; i formati di interscambio sono a pagamento, sulla stessa linea che questa edizione ha sempre tracciato: leggere i propri numeri è gratis, alimentare una pipeline CI no.

Corretto

• Un file che non ha nulla da strumentare non viene più riportato come coperto al 100%. Un header di sole dichiarazioni — prototipi, una macro, include guard — non ha corpi di funzione, quindi il compilatore non emette alcuna mappatura di copertura per esso, e tutto ciò che divide zero per zero risponde 100%. Compariva in verde nell’albero, accanto a codice davvero testato. Entrambi i lettori prendono ora i totali dello strumento stesso come resoconto che il file dà di sé — LF/FNF/BRF in lcov, il blocco summary nel JSON di llvm-cov — e un file i cui totali sono tutti zero resta fuori dall’esecuzione invece di essere valutato. I record riga per riga sotto quei totali vengono ignorati di proposito: l’espansione di una macro è attribuita alla riga che la definisce mentre il conteggio appartiene alla riga che la usa, in un altro file, e quella riga presa in prestito era l’unico motivo per cui un header simile sembrava misurato. Anche i totali dell’esecuzione la perdono, così la cifra principale è un po’ più bassa e molto più vera. Ogni percorso escluso è nominato nel canale di output, e un report in cui ogni file è di sole dichiarazioni li mantiene tutti.

Modificato

• Selezionare un file di copertura si aggiunge a quanto è già caricato invece di sostituirlo. Una build che scrive un report per modulo non ha un singolo file da fissare, e selezionare il report del secondo modulo scaricava in silenzio il primo. La finestra accetta ora più file per volta, ogni selezione si aggiunge all’insieme e tutto ciò che è selezionato viene unito in un’unica esecuzione, disegnata nel pannello sotto il nome proprio di ciascun progetto. Il monitoraggio li segue tutti e un report rigenerato non toglie più gli altri dallo schermo. Show Loaded Coverage Files termina con Scarica i file selezionati, che riporta alla ricerca ordinaria.
• L’assistenza ha un indirizzo sul dominio del prodotto: support@fucini.software. Quando l’attivazione non riesce da sola, il pannello della licenza e il messaggio del codice di richiesta indicavano un indirizzo fucini.consulting: un dominio diverso da ogni altro collegamento dell’estensione, che si legge come un’altra azienda. license@fucini.software resta com’è: invia le chiavi, non è una casella a cui scrivere.

Aggiunto

• Ogni albero della vista Coverage dice ora a quale progetto appartiene. La 0.2025.19 dava a un'esecuzione unita un blocco con nome per progetto, ma un'esecuzione ordinaria disegnava ancora un albero nudo — così un'area di lavoro ridotta alla propria cartella si apriva su src, senza che nulla sopra dicesse quale src. Ogni albero porta ora la propria radice: le cartelle che portano al progetto nel colore attenuato, la cartella propria del progetto dopo di esse a pieno colore. Un albero ridotto alla cartella dell'area di lavoro dice comunque a che cosa è stato ridotto, e due basi di codice unite in una sola esecuzione non vengono mai lette come un solo albero. È un'intestazione, non una riga: lì non c'è nulla da espandere, e le cartelle sottostanti si richiudono esattamente come prima. In un pannello stretto si accorciano per prime le directory iniziali, così la cartella che dà davvero il nome al progetto è l'ultima ad andarsene, e passandoci sopra si vede l'intero percorso.

Aggiunto

• Le righe della vista Coverage hanno il menu contestuale di Esplora risorse. Il clic destro su un file o una cartella apriva finora il Taglia/Copia/Incolla della webview: tre voci senza nulla su cui agire. Ora apre il vero menu di VS Code: Apri, Open to the Side, Apri con…, Reveal in Explorer View, Reveal in File Explorer, Open in Integrated Terminal, Trova nella cartella… per una cartella e Copy Path / Copy Relative Path, con accanto le varianti con le barre su Windows, dove le due forme differiscono. Il pulsante ⋯ e il suo menu restano invariati e sono l'ultima voce del nuovo menu.

Modificato

• Una metrica per cui il tracefile non porta dati non viene più giudicata. Una soglia su MC/DC senza MC/DC nella build contava come fallimento: un file al 100% su ogni metrica davvero misurata finiva sotto una scheda con «3 su 5 soddisfatte», contro un'asticella che nulla in quel tracefile avrebbe mai potuto superare. Le metriche senza dati vengono ora saltate ovunque si formi un verdetto: la barra di stato per file, la scheda dell'intera esecuzione, il banner del sorgente annotato e il report HTML. Check Coverage Thresholds continua a nominare esplicitamente una metrica assente, che è il posto giusto.
• I file senza nulla di misurabile restano fuori dalla vista Coverage. Un header di dichiarazioni, un file di soli riesporti, un modulo di soli tipi: nessun test che scriverai cambierà il loro numero, e aprirli non mostra alcuna metrica. In 0.2025.19 avevano un trattino; ora semplicemente non compaiono, e le cartelle che restano vuote se ne vanno con loro. Un'esecuzione in cui nulla è misurabile elenca ancora tutto.

Corretto

• Una lettera di unità poteva ancora stare in cima all'albero. Con copertura i cui percorsi non stanno sotto la cartella di lavoro aperta — un tracefile unito da un altro progetto, o una finestra senza cartella aperta — l'albero iniziava da W:, o su Linux e macOS da una riga senza alcun nome: una riga con esattamente un figlio, espandibile a vuoto. La radice del filesystem non viene più disegnata, qualunque aspetto abbiano i percorsi, e ogni riga conserva il suo vero percorso assoluto per il menu e l'editor.

Aggiunto

• Un menu di riga su ogni file e cartella nella vista Coverage. Il pulsante in fondo alla riga copia quel percorso in ciascuna delle quattro forme che un editor, una shell o un prompt possono volere — assoluto o relativo all'area di lavoro, con i separatori del sistema o con le barre — e offre Reveal in File Explorer e Open in Integrated Terminal, con un file che apre il terminale nella propria directory. Le voci con le barre compaiono solo dove differiscono dalla forma nativa, quindi su Linux e macOS il menu è più corto di due voci. Copiare un percorso significava finora ritrovare lo stesso file una seconda volta in Esplora file.
• Pulsanti per comprimere ed espandere tutto sopra l'albero. Comprimere tutto e poi aprire l'unica cartella che interessa è la via più rapida in un albero grande, e finora costava un clic per cartella. Ciò che comprimi così viene ricordato esattamente come una cartella chiusa a mano, quindi un ricaricamento non lo annulla.
• Un'esecuzione unita che copre più progetti disegna ora ogni progetto separatamente, sotto il proprio nome. Unire un file di traccia di una seconda base di codice appendeva le sue cartelle allo stesso albero di quelle dell'area di lavoro, così src compariva due volte senza dire perché e le directory dei due progetti si mescolavano in ordine alfabetico. Ogni progetto riceve ora un proprio blocco con nome, separato da una riga, con quello dell'area di lavoro per primo. Un'esecuzione che copre un solo progetto è invariata e non porta intestazione: non ci sarebbe nulla da cui distinguerla.

Corretto

• Un file senza nulla di eseguibile veniva riportato come coperto allo 0%. Un modulo fatto solo di riesportazioni export *, o solo di dichiarazioni di tipo, si compila in qualcosa che nessuno strumento di copertura può misurare — il file di traccia non registra quindi alcuna istruzione per esso. La vista Coverage lo valutava 0% e lo metteva in rosso accanto a codice davvero non testato, benché non ci sia nulla per cui scrivere un test; nel frattempo Esplora file assegnava allo stesso file un 100% verde, perché un totale vuoto si legge come "tutto di niente è coperto". Nessuno dei due numeri era vero e nessuno viene più mostrato: la riga del pannello riceve un trattino e un contorno tratteggiato, con un suggerimento che spiega perché, e il badge di Esplora file viene omesso. Anche una cartella che contiene solo file simili resta senza punteggio. Un file che è allo 0% di qualcosa che è stato davvero misurato mostra ancora 0%: il trattino significa "niente da misurare", non "misurato e mancato".
• Le righe di un progetto unito puntavano nel posto sbagliato. I loro percorsi erano costruiti dalla radice dell'area di lavoro anziché dalla propria, così per un file fuori dall'area di lavoro il menu di riga copiava — e "Reveal in File Explorer" apriva — un percorso in cui il file non è mai stato. Ora portano la radice da cui provengono davvero.

Modificato

• La vista Coverage non disegna più la radice dell'area di lavoro. L'albero partiva dalla radice del file system e scendeva attraverso ogni cartella sopra il progetto — il disco, poi la directory che contiene i tuoi progetti, poi il progetto stesso — prima di arrivare alla prima cartella davvero tua. Erano diversi livelli di rientro, su ogni riga, a ripetere quello che il titolo della finestra diceva già. I percorsi ora partono dalla cartella dell'area di lavoro. Il percorso assoluto completo resta ciò che il menu di riga copia e ciò che l'editor apre.

Corretto

• Le cartelle compresse nella vista Coverage si riaprivano a ogni ricaricamento. Il monitoraggio è attivo per impostazione predefinita, quindi una build che rigenera la copertura ridisegna il pannello — e poiché ogni cartella veniva disegnata aperta, comprimerne una durava solo fino alla build successiva. Su un albero grande significava rifare lo stesso lavoro più volte in un'ora. Ora il pannello ricorda quali cartelle ha chiuso e le lascia chiuse. Una directory che compare per la prima volta in un'esecuzione successiva viene comunque mostrata aperta, come qualsiasi altra: ciò che viene ricordato è il gesto deliberato di chiuderne una, non lo stato predefinito.
• Disattivare la telemetria non fermava il segnale di disinstallazione. Quel segnale viene inviato da un piccolo script autonomo che VS Code esegue durante la disinstallazione. Non ha accesso all'API di VS Code e non può leggere le sue impostazioni, quindi l'unica cosa che gli dice di non inviare nulla è l'assenza di un file che l'estensione scrive mentre la telemetria è attiva — e quel file non veniva mai rimosso quando si disattivava la telemetria. Chiunque l'avesse attivata e poi disattivata avrebbe comunque inviato, alla disinstallazione, il proprio nome utente del sistema operativo, il nome host e la cartella home. Ora il file viene eliminato non appena la telemetria è disattivata.
• Un rinnovo Pro poteva segnalare un esito positivo per una chiave appena sostituita. Il rinnovo silenzioso leggeva la chiave configurata due volte: una per decidere se rinnovare, e di nuovo dopo per decidere se mostrare un messaggio. Incollare una nuova chiave mentre un rinnovo era in corso faceva sì che la seconda lettura vedesse una chiave diversa, e il messaggio “il suo abbonamento Pro è stato rinnovato” descriveva quella appena sostituita. Ora la chiave viene letta una sola volta.

Modificato

• Ogni modulo dell'estensione è ora coperto dai propri test. Per uno strumento il cui unico compito è dirle fin dove arrivano davvero i suoi test, valeva la pena farlo bene: 53 dei 54 file sorgente sono al 100% per istruzioni, branch, funzioni e righe, e il restante — lo strato di collegamento con VS Code — al 95% delle sue funzioni. Scriverli ha fatto emergere i difetti descritti sopra, insieme a una ventina di controlli che non potevano mai essere eseguiti: percorsi di ripiego posti dietro verifiche che li avevano già esclusi, che sembravano reti di sicurezza ma non intercettavano nulla. Sono stati rimossi invece di essere mascherati con un test che non poteva fallire.

Modificato

• Il sondaggio facoltativo ora attende che tu abbia davvero usato lʼestensione e chiede in un momento migliore. Contava i giorni di calendario dallʼinstallazione, misurando da quanto tempo lʼavevi installata anziché se lʼavessi mai vista funzionare: unʼinstallazione rimasta intatta per un mese si vedeva chiedere di valutare un prodotto che non le aveva mai mostrato nulla. Ora servono caricamenti di copertura reali oltre al tempo trascorso, e non compare più mentre lʼeditor si avvia: attende che un caricamento sia riuscito. Dopo un anno arriva un terzo e ultimo invito, perché due nello stesso trimestre escludevano per sempre chiunque fosse semplicemente occupato in quel periodo.
• La traduzione neerlandese non è più formale. Si rivolgeva ovunque con «u», che per uno strumento di sviluppo suona rigido e non corrispondeva a nulla del resto della voce del prodotto. Tutti i testi neerlandesi usano ora «je», riscritti frase per frase, perché il cambiamento trascina con sé le forme verbali.

Modificato

• Il modulo di attivazione chiedeva un «company code» agli sviluppatori singoli. Chi acquista Pro o Pro Plus da solo riceve un codice dal proprio abbonamento: non c’è nessuna azienda dietro, e vederselo chiedere fa pensare di essere sul modulo sbagliato. Quel campo ora si chiama Subscription code per Pro e Pro Plus e resta Company code per Business ed Enterprise, dove un team ne condivide davvero uno. I suggerimenti sotto erano già scritti per piano; era rimasta generica solo l’etichetta.

Risolto

• Il report HTML generato giudicava il codice rispetto al 100%, quali che fossero le soglie impostate. La colonna Stato confrontava ogni metrica con un 100 nascosto: un progetto che fissava le proprie soglie a 80 e le rispettava vedeva un banner verde COMPLIANT proprio sopra una colonna di croci rosse, per la stessa esecuzione e sulla stessa pagina. La legenda delle metriche faceva lo stesso. Entrambe ora usano le tue soglie e, dove nessuna si applica, mostrano un trattino spento invece di inventare un verdetto.
• Il banner di conformità affermava più di quanto avesse verificato. Diceva sempre «tutte le soglie configurate soddisfatte», anche nella modalità predefinita, che valuta solo il punteggio ponderato: un'esecuzione poteva quindi affermare che ogni soglia era soddisfatta mentre una falliva ben visibile nella tabella sottostante. Ora ogni modalità dichiara la regola che ha realmente applicato.
• Il README diceva che l'estensione «è gratuita fino al 2026-12-31». Quella data non esiste nel prodotto. Una release precedente aveva corretto l'affermazione nelle descrizioni delle impostazioni ma aveva saltato il README, la prima cosa che si legge sul Marketplace. Ora dice cosa accade davvero: 14 giorni di prova dal primo utilizzo, poi il livello Community gratuito, senza alcuna data dopo la quale qualcosa smetta di funzionare.

Modificato

• Le due edizioni non sono più identiche nel Marketplace. Pro e Community vengono compilate dallo stesso albero di sorgenti, e finora questo includeva anche l'icona: le due schede erano quindi la stessa immagine con didascalie diverse, affiancate negli stessi risultati di ricerca. Ora ogni edizione ha la propria: la stessa grafica con una fascia colorata in basso, turchese per Pro e ardesia per Community. È la parola a distinguerle quando l'icona è mostrata grande; in una riga di risultati la parola è troppo piccola da leggere, e allora ci pensa il colore.

Risolto

• Aprire la vista annotata non ti impedisce più di riaprirla. Il pannello del sorgente annotato è una webview e non un editor di testo, quindi finché aveva il fuoco l'estensione non vedeva alcun «file corrente», e Open Annotated Source rispondeva lì «apri prima un file con la copertura caricata», a chi stava guardando proprio la vista annotata di un file che la copertura ce l'ha. Ora ricade sul file dietro il pannello che hai davanti. Lo stesso blocco saltava in silenzio anche il ricontrollo per cui esiste una seconda esecuzione: quando è configurato un report HTML llvm-cov, è proprio la seconda esecuzione a portare il pannello sulla pagina di quel report — quindi se la tua build di copertura finiva dopo l'apertura del pannello, dal pannello stesso non c'era modo di recuperarla.

Aggiunto

• Un abbonamento Pro a pagamento ora si rinnova da solo. Ogni chiave di attivazione dura esattamente quanto il periodo pagato. I piani per team recuperano il periodo rinnovato al contatto successivo, ma Pro individuale non contatta mai il server — funziona completamente offline — quindi nulla gli portava il rinnovo, e la chiave di un abbonato mensile sarebbe scaduta più o meno ogni mese per quanto puntualmente pagasse. L'estensione ora chiede una chiave nuova in silenzio, solo nei giorni attorno alla propria scadenza e solo quando possiede il codice che prova che un abbonamento l'ha pagata. Restare offline in quella finestra non costa nulla: la chiave continua a funzionare fino alla scadenza reale, e il tentativo successivo la ripristina.
• Attivare dall'e-mail di acquisto è un clic. Il link passa all'estensione piano e codice direttamente, invece di aprire VS Code, cercare il comando e incollare il codice a mano. Chiede sempre conferma prima di usare una postazione. Inserire il codice a mano funziona esattamente come prima — il link è una scorciatoia, mai l'unica strada — e funziona anche nella versione Community.

Risolto

• La descrizione di un'impostazione affermava che l'estensione è "gratuita fino al 2026-12-31". Quella data non esiste da nessuna parte nel prodotto. Quello che accade davvero è una prova di 14 giorni dal primo utilizzo, dopo la quale l'estensione torna al livello gratuito Community. Ora è questo che dice, in ogni lingua.
• Le impostazioni di soglia non citano più la versione che ne ha cambiato i valori predefiniti: un numero di versione a metà frase risponde a una domanda che nessuno si pone leggendo la descrizione di un'impostazione.
• Diverse descrizioni tradotte nominavano un comando che nessun VS Code tradotto mostra. Si riferivano al comando di attivazione con il nome inglese, mandando chi non lavora in inglese a cercare nella palette comandi una stringa che lì non c'è.

Risolto

• Un progetto senza decisioni MC/DC poteva mostrare una copertura complessiva dello 0%. Alcuni strumenti segnalano una sezione MC/DC anche quando non c’è nulla da misurare, e questo veniva letto come «0% coperto» anziché «nulla da coprire». Poiché il punteggio complessivo scende a zero non appena una metrica vale zero, un progetto interamente coperto poteva mostrare 0%. Una metrica senza nulla da misurare ora non rientra affatto nel punteggio e la sua riga scompare invece di comparire come «0 / 0 condizioni coperte».
• Lo stato della licenza è ora tradotto in tutte e 17 le lingue. Restava in inglese ovunque e, poiché compare all’interno di frasi già tradotte, il risultato era una riga tradotta a metà nella barra di stato, nelle notifiche e nel pannello dei file coperti.
• Anche la vista Sorgente annotato e i suggerimenti di copertura sono tradotti — la tabella di dettaglio della conformità, i pulsanti di navigazione con i relativi suggerimenti e il dettaglio di rami e MC/DC.

Modificato

• Un abbonamento Pro a pagamento può ora essere attivato con il proprio codice. L’elenco dei piani nella richiesta di chiave ha ora una voce Pro, così il codice che arriva con un abbonamento Pro ha finalmente dove essere inserito. Le chiavi Pro individuali continuano a funzionare completamente offline e dopo l’attivazione non contattano mai il server.
• L’icona nella barra delle attività è più grande e più visibile accanto alle icone integrate.
• Il passaggio all’edizione Community ora la installa da fucini.software. Prima si tentava dal Marketplace, dove l’edizione Community non è pubblicata, quindi il passaggio poteva lasciarti senza alcuna estensione installata.

Modificato

• Un abbonamento scaduto ora si assesta sul piano gratuito — quando una chiave di attivazione individuale si esauriva, l'estensione continuava a chiederti di rinnovarla all'infinito. Scegliere di non rinnovare è una normale fine di un abbonamento, non un guasto, quindi ora l'estensione passa invece al piano Community gratuito e permanente. I piani per team non ne sono volutamente toccati: una chiave Pro Plus, Business o Enterprise scaduta continua a essere segnalata come scaduta, perché lì è un amministratore a doverla rinnovare e far scivolare in silenzio l'intera azienda sul piano gratuito lo nasconderebbe.

Risolto

• La disattivazione della telemetria ora viene rispettata in ogni caso. Un percorso di codice poteva saltare il controllo quando era attiva la modalità interna di diagnostica dettagliata dell'estensione. Quella modalità è disattivata in ogni build pubblicata, quindi nessuna release si è mai comportata così, ma ora il controllo è incondizionato.
• Le impostazioni si applicano subito invece di attendere un ricaricamento. Modificare la rimappatura dei percorsi, l'esclusione dei commenti, il filtro git-diff o i totali dei file esclusi ora ricarica la coverage immediatamente — in particolare la rimappatura dei percorsi, dato che è proprio l'impostazione a cui ricorri quando i percorsi non coincidono.
• "Unlock Full Features" e "Switch to Community" potevano fermarsi a metà senza dirlo. Entrambe ora arrivano fino in fondo.
• La tua chiave di attivazione resta legata alla stessa identità della macchina. In alcune configurazioni quell'identità poteva essere rigenerata tra una sessione e l'altra, il che invalidava una chiave già emessa.

Aggiunto

• Traduzioni complete in tutte le 17 lingue distribuite — circa un centinaio delle stringhe di interfaccia più recenti, tra cui le finestre di dialogo di attivazione e licenza, il sondaggio di feedback facoltativo, il flusso di sblocco Community e le notifiche di aggiornamento automatico, ricadevano ancora sull'inglese in ogni pacchetto non inglese. Tutte le 17 lingue coprono ora l'intera interfaccia a runtime dell'estensione.

Modificato

• Passata di riordino su commenti del codice sorgente, documentazione degli script di build ed elenco dei file di pacchettizzazione. L'insieme dei file distribuiti nell'estensione è invariato; nessuna modifica funzionale o di comportamento.

Risolto

• Installare contemporaneamente le edizioni Pro e Community poteva far bloccare una delle due all'avvio — registrano gli stessi comandi e la stessa vista dei file di coverage. Ora viene rilevato in anticipo: se anche l'altra edizione è installata, l'attivazione si interrompe in modo pulito con un messaggio che ti invita a disinstallarne una, invece di un errore di attivazione inspiegabile.

Versione di manutenzione; nessuna modifica funzionale.

Un piano gratuito permanente, piani per team che condividono un pool di postazioni e un'edizione Community separata dell'estensione.

Aggiunto

• Un piano Community gratuito e permanente — invece di un blocco netto al termine della prova di 14 giorni, l'estensione ora passa a Community: tutte le funzionalità tranne MC/DC, un assaggio mensile limitato del Full HTML Report e delle viste Annotated Source persistenti, generosi limiti giornalieri su una manciata di azioni automatizzabili e tutto il resto senza limiti.
• Sblocca ogni funzionalità gratuitamente — un nuovo comando "Unlock Full Features" scambia telemetria d'uso dettagliata con un'abilitazione completa e senza restrizioni, reversibile in qualsiasi momento. Un sondaggio di feedback facoltativo nell'app offre in alternativa una chiave completa di 30 giorni, senza alcun obbligo.
• Piani per team: Pro Plus, Business ed Enterprise — questi condividono un pool di postazioni (un codice aziendale più un numero di postazioni) invece di una chiave per macchina, con un controllo periodico in background che mantiene aggiornata l'abilitazione di una postazione e segnala automaticamente una postazione revocata o ridotta.
• Fucini Coverage Studio Community — una pubblicazione separata e dedicata, creata dallo stesso codice sorgente, in cui il codice di prova/attivazione/piani per team a pagamento è realmente assente e non semplicemente nascosto. Vedi la pagina dei download.

Modificato

• La generazione del Full HTML Report e le viste Annotated Source persistenti (semplice e affiancata) sono ora funzionalità dei piani a pagamento nella base Community — resta solo la vista a scambio sul posto, limitata mensilmente come prima. Lo sblocco continua a concedere tutto quanto.
• Un avviso di limite d'uso sul piano Community ora offre entrambe le strade in un unico messaggio: vedere i piani a pagamento oppure sbloccare tramite telemetria.

Risolto

• La telemetria dettagliata e potenzialmente identificativa (nome utente del sistema operativo, directory home, specifiche CPU/RAM, interfacce di rete e il contenuto completo di report e sorgenti) può ora essere inviata soltanto da Community o da un'abilitazione gratuita condizionata alla telemetria — mai da una licenza a pagamento Pro/Pro Plus/Business/Enterprise, indipendentemente dalle impostazioni di telemetria locali.
• Un'installazione che eseguiva già una build precedente non riceve più una nuova finestra di prova solo perché è stata aggiornata — ora passa correttamente al piano Community se la sua vecchia prova era già scaduta.
• La notifica di aggiornamento, l'avanzamento del download e i messaggi di errore mostrano ora la versione semplice Major.Year.Minor (la stessa che appare nella vista Extensions di VS Code) invece di rivelare il numero di build interno, ad es. 0.2024.6 invece di 0.2024.6.2.

Le chiavi di attivazione ora possono limitare singole funzionalità separatamente, e gli amministratori delle licenze possono emettere a mano una chiave calibrata dalla dashboard.

Aggiunto

• Limiti d'uso per funzionalità — le chiavi di attivazione possono ora limitare ogni funzionalità/azione in modo indipendente (ad esempio, le esportazioni del report HTML a 1 al mese) invece di un unico limite condiviso sui caricamenti di coverage. Le chiavi esistenti continuano a funzionare invariate.
• Emissione manuale delle chiavi — gli amministratori delle licenze possono ora emettere a mano una chiave per un codice di richiesta ricevuto al di fuori del questionario nell'editor, scegliendo esattamente quali funzionalità concedere, una scadenza e i limiti per funzionalità, con la chiave inviata automaticamente via e-mail quando viene fornito un indirizzo.

Corregge un bug di caching che poteva nascondere le nuove versioni agli utenti dietro determinati proxy aziendali.

Risolto

• Affidabilità del feed di aggiornamento automatico — il manifest di aggiornamento viene ora servito con un'intestazione no-cache rigorosa, così un proxy con cache tra fucini.software e il lettore non può più servire una copia obsoleta che nasconde le nuove versioni.

Una piccola release di manutenzione: alcune correzioni minori di bug e miglioramenti delle prestazioni.

Risolto

• Correzioni di bug — correzioni minori di bug e miglioramenti della stabilità.
• Prestazioni — piccoli miglioramenti delle prestazioni nel caricamento e nel rendering della coverage.

Le chiavi di attivazione vengono ora rilasciate e applicate automaticamente — niente più attese di un'email.

Modificato

• Attivazione automatizzata — richiedere una chiave ora invia un breve questionario e applica automaticamente la chiave ricevuta alle tue impostazioni, senza scambio di email.
• Rinnovi più rapidi — una richiesta di rinnovo pone solo domande su utilizzo e desideri; i tuoi dati di contatto di una richiesta precedente vengono riutilizzati, mai richiesti di nuovo.
• Finestra di valutazione fissa — la prova ora dura per tutti fino al 31/12/2026, sostituendo il precedente conto alla rovescia di 14 giorni dall'installazione.
• Flusso di attivazione localizzato — il questionario di rinnovo e le conferme di attivazione sono ora tradotti in tutte le 18 lingue supportate, come il resto dell'estensione.

L'estensione ora controlla gli aggiornamenti sia su fucini.software sia sul VS Code Marketplace, offrendo sempre la versione più recente.

Risolto

• Controllo da due fonti — ora interroga sia fucini.software sia il VS Code Marketplace, offrendo la versione più recente.

Prima versione pubblica di Fucini Coverage Studio — coverage nativa per VS Code che importa file di traccia degli standard di settore, li normalizza in un unico modello canonico, unisce le esecuzioni in modo deterministico e genera report tramite l'API Test Coverage integrata di VS Code.

Aggiunto

• Importazione multi-formato — LCOV, llvm-cov JSON, Cobertura XML, JaCoCo XML, Istanbul/nyc e SimpleCov JSON, rilevati automaticamente.
• Unione deterministica — più file di traccia combinati in un'unica esecuzione con provenienza registrata, stabile indipendentemente dall'ordine di caricamento.
• UI di coverage nativa — indicatori di riga/ramo/funzione, righello di panoramica e pannello Test Coverage integrato.
• Coverage MC/DC — dettaglio per decisione al passaggio del mouse e un indicatore di margine colorato opzionale.
• Punteggio composito — una media armonica ponderata SIL su righe, rami, funzioni, regioni, MC/DC e istanziazioni C++.
• Verdetto di conformità — controllo COMPLIANT / NON-COMPLIANT con le modalità strict, whm, both ed either.
• Rimappatura dei percorsi, coverage differenziale, badge Explorer e una barra di stato globale.
• Analisi nell'editor — CodeLens di funzione, hover sui rami, avvisi di codice morto, avvisi di coverage obsoleta e Next/Previous Uncovered.
• Vista dei file coperti, report HTML, cronologia e tendenze, modalità watch ed esportazione Fucini JSON.