Journal des modifications

Corrigé

• Le dossier d’où vous lancez la commande ne décide pas de ce que signifie un rapport. 2.2026.3 rattache les chemins relatifs d’un rapport au dossier où ce rapport a été écrit — mais seulement pour une commande lancée ailleurs. Lancée depuis la racine de l’arbre qu’elle mesure, c’est-à-dire là où une commande de couverture se lance d’ordinaire, un chemin relatif était encore résolu par ce dossier, et un fichier que llvm-cov avait déjà nommé en entier était compté une seconde fois : un arbre de 5 258 lignes se lisait 5 836. Seuls --cwd et l’emplacement du rapport décident désormais. La même correction est dans les deux éditeurs, où le dossier était celui depuis lequel VS Code ou Visual Studio avait été lancé.
• export --format json écrivait le run par-dessus vos réglages. Son fichier était fucini-coverage.json — le nom d’où les réglages sont lus — de sorte que, dans un dossier configuré de façon ordinaire, l’export détruisait les seuils selon lesquels il venait de juger. Le run est écrit dans coverage-run.json, et export et badge refusent un --out qui nomme le fichier de réglages.
• --cwd accepte un dossier quelle que soit la façon de l’écrire. Un dossier relatif — --cwd ., --cwd ../tree — était conservé tel quel et lu selon les mauvaises règles de chemin : sous Windows, il répondait qu’un fichier de réglages moitié POSIX moitié Windows ne pouvait être lu, et ne trouvait aucun rapport. Un séparateur final ne fait plus partie du dossier non plus.
• Une option que personne n’a déclarée n’est pas un rapport. summary -o out.json prenait -o pour un rapport et annonçait qu’un tel fichier n’existe pas. Seules -h et -v sont courtes ; -- passe toujours un fichier dont le nom commence par un tiret, et une option tapée avant la commande est nommée dans l’erreur au lieu d’être traitée par l’aide entière.
• check --json dit ce que dit son code de sortie. Sans seuil défini, il écrivait "passed": false à côté du code de sortie 0, et un pipeline qui lisait le JSON plutôt que le code de sortie faisait échouer un run que la commande avait réussi. passed est le code de sortie en un mot ; configured est ce qui dit qu’il n’y avait pas de seuil. Un --lines "" vide est refusé au lieu d’éteindre ce seuil en silence.
• Une comparaison place la baseline là où elle place le run. pathRemap et la racine déclarée par un rapport s’appliquaient au run et non à la baseline : une baseline écrite sur un serveur de build ne s’appariait à rien, et la comparaison annonçait que rien n’avait bougé à côté d’un total qui avait manifestement bougé.

Corrigé

• Les chemins relatifs d’un rapport se rattachent au dossier où ce rapport a été écrit. llvm-cov écrit le chemin complet d’un fichier ; gcovr l’écrit relativement au dossier de build où se trouve son rapport. Avec les deux rapports d’un même arbre, summary listait deux fois chaque fichier commun aux deux — une fois avec les chiffres de chaque moteur — et ajoutait les deux au total, parce qu’un chemin relatif n’avait aucune racine contre laquelle se résoudre et se résolvait contre le dossier où se trouvait le shell à ce moment-là. Un arbre de 5 258 lignes était annoncé à 5 836, le surplus appartenant à des fichiers sous un chemin qui n’en contient aucun. Chaque rapport est désormais ancré à son propre dossier et à ceux au-dessus, jusqu’au dossier où la commande s’exécute, comme le font déjà les deux éditions — les deux se rejoignent ainsi en un seul ensemble de fichiers, sans une règle pathRemap par répertoire de build.
• Un fichier de paramètres commençant par une marque d’ordre d’octets était refusé lui aussi. Un éditeur sous Windows peut en écrire une devant le texte ; elle n’est plus prise pour une partie du JSON.
• Une sortie redirigée vers un lecteur qui s’arrête tôt se termine sans bruit. summary redirigé vers head, ou vers le Select-Object -First de PowerShell, mourait sur un EPIPE non géré avec une trace de pile. Que le lecteur ferme le tube est son choix, pas un échec de la commande : elle se termine maintenant avec le code de sortie qu’elle avait atteint.

Corrigé

• Un fichier de paramètres contenant des motifs était refusé. Avec **/*.lcov.info dans un chemin de fuciniCoverage.coverageFile.paths et **/coverage.json dans le suivant, chaque commande se terminait par is not JSON : ce qui se trouvait entre les deux était pris pour un commentaire. Le fichier est désormais lu comme les éditeurs le lisent, y compris un commentaire après une valeur et une virgule avant un crochet fermant.

Ajouté

• Le lecteur en ligne de commande, gratuit. npm install -g fucini-coverage — le même lecteur que les deux éditions, pour les endroits où il n’y a pas d’éditeur. Un seul paquet, un seul comportement sur Windows, Linux, WSL et macOS, Node 20 ou plus récent.
• check, le contrôle des seuils. Code de sortie 1 sous un seuil sur les lignes, les branches, les fonctions, MC/DC, les conditions, les régions, la mutation ou le score pondéré, d’après les réglages ou la ligne de commande ; --new-code 80 --base-ref origin/main juge les lignes qu’une branche a modifiées, d’après un git diff lancé par l’outil ; --require-reasons fait échouer un marqueur d’exclusion sans raison.
• summary, export, report, badge, compare. Les totaux et chaque fichier ; l’exécution en CSV par fichier ou par fonction, Markdown, LCOV, Cobertura, SARIF, la liste des exclusions, un badge ou le JSON de Fucini ; le rapport HTML multipage ; le badge coloré selon l’échelle des réglages ; cette exécution par rapport à une référence, les régressions d’abord, avec --fail-on-regression pour une vérification de pull request.
• mcp, pour un agent IA. Les six outils des éditions, servis sur l’exécution, sur 127.0.0.1 derrière un jeton, l’entrée pour le mcp.json du client étant affichée.
• Le fichier de réglages de l’édition Visual Studio. fucini-coverage.json à côté du code, avec les clés fuciniCoverage.* des réglages de VS Code ; .vscode/settings.json en dessous. Les rapports se nomment par fichiers, dossiers ou motifs, un .gz est décompressé, et chaque commande se documente elle-même : fucini-coverage help <command>.

Modifié

• L’essai d’une nouvelle installation commence avec la première réponse du serveur de licences. Tant que l’extension n’a pas joint fucini.software une fois, elle fonctionne au niveau Community et dit pourquoi. Une installation déjà en période d’essai, ou qui a une licence, ne remarque rien.
• Pas d’essai dans un conteneur de développement ou un Codespace. L’extension y démarre au niveau Community ; un code d’abonnement, une clé ou le pass de 7 jours débloque tout.
• Le registre d’utilisation connaît une machine par un second hachage, celui de l’identifiant propre au système d’exploitation. Seul le hachage est envoyé ; voir la politique de confidentialité.

Corrigé

• Petites corrections. Une version de maintenance : de petites corrections en coulisses, et rien qui change ce que vous voyez ni la façon de l’utiliser.

Corrigé

• Petites corrections. Une version de maintenance : de petites corrections en coulisses, et rien qui change ce que vous voyez ni la façon de l’utiliser.

Ajouté

• La couverture à l’écran, pour les agents IA. Un agent qui écrit des tests pouvait les exécuter et lire un pourcentage ; il ne pouvait pas demander ce que sait Visual Studio. Six outils y répondent, en des termes sur lesquels un agent peut agir : coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta et test_run_command. Un agent qui parle MCP les atteint par un serveur que Visual Studio fait tourner quand fuciniCoverage.mcp.enabled est activé — désactivé par défaut, sur 127.0.0.1 uniquement, derrière un jeton qui vous est propre, et fermé aux pages web. Copy MCP Server Configuration met l’entrée du client dans le presse-papiers.
• Les mêmes chiffres qu’à l’écran. Les outils répondent à partir de l’exécution chargée — les mêmes exclusions, le même remappage —, si bien qu’un agent chargé de couvrir les lacunes d’une fonction et un relecteur qui regarde la marge parlent des mêmes lignes.

Modifié

• Le forfait d’une clé décide dans Visual Studio ce qu’il décide dans VS Code. Un forfait qui exclut une fonctionnalité — MC/DC, le rapport HTML, les noms des tests qui ont exécuté une ligne — l’excluait dans VS Code et pas ici. Les deux éditions lisent désormais la même table : une fonctionnalité que le forfait n’inclut pas n’est pas proposée, et sa commande le dit.
• La version minimale que demande le serveur de licences vaut ici aussi. Les deux éditions portent la même version à partir de la 2.2026.0, si bien qu’une build plus ancienne que ce minimum demande à être mise à jour, comme le fait l’édition VS Code.

Ajouté

• La couverture à l’écran, pour les agents IA. Un agent qui écrit des tests pouvait les exécuter et lire un pourcentage ; il ne pouvait pas demander ce que sait l’éditeur. Six outils y répondent, en des termes sur lesquels un agent peut agir : coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta et test_run_command. L’agent de VS Code lui-même les a comme outils de modèle de langage, sans rien à configurer. Tout autre agent qui parle MCP les atteint par un serveur que l’extension fait tourner quand fuciniCoverage.mcp.enabled est activé — désactivé par défaut, sur 127.0.0.1 uniquement, derrière un jeton qui vous est propre, et fermé aux pages web. Copy MCP Server Configuration met l’entrée du client dans le presse-papiers.
• Les mêmes chiffres qu’à l’écran. Les outils répondent à partir de l’exécution chargée — les mêmes exclusions, le même remappage —, si bien qu’un agent chargé de couvrir les lacunes d’une fonction et un relecteur qui regarde la marge parlent des mêmes lignes.

Corrigé

• Un fichier mesuré par deux moteurs est un seul fichier. llvm-cov écrit le chemin complet d’un fichier ; gcovr l’écrit relativement au dossier de build où se trouve son rapport. Un chemin relatif est rattaché au dossier du rapport et à ceux au-dessus — mais, avant cela, le résolveur demandait si le chemin existait tel quel, et cette question reçoit sa réponse depuis le dossier où Visual Studio lui-même a été lancé. Si ce dossier contenait le fichier, le chemin restait relatif : le fichier avait deux noms, apparaissait deux fois dans la fenêtre Coverage et comptait deux fois dans les totaux. Un arbre de 5 258 lignes se lisait 5 836. Un chemin qui ne nomme aucun emplacement propre n’est plus soumis à cette question ; il est rattaché là où le rapport a été écrit, et la ligne le dit.

Corrigé

• Un fichier mesuré par deux moteurs est un seul fichier. llvm-cov écrit le chemin complet d’un fichier ; gcovr l’écrit relativement au dossier de build où se trouve son rapport. Un chemin relatif est rattaché au dossier du rapport et à ceux au-dessus — mais, avant cela, le résolveur demandait si le chemin existait tel quel, et cette question reçoit sa réponse depuis le dossier où l’hôte d’extensions a été lancé, c’est-à-dire, après code ., la racine de votre projet. Le chemin restait alors relatif : le fichier avait deux noms, apparaissait deux fois dans la vue Coverage et comptait deux fois dans les totaux. Un arbre de 5 258 lignes se lisait 5 836. Un chemin qui ne nomme aucun emplacement propre n’est plus soumis à cette question ; il est rattaché là où le rapport a été écrit, et la ligne le dit.
• Le mode de gouttière que vous choisissez tient pour la session, et vos réglages restent tels que vous les avez écrits. Choisir un mode dans la barre d’état, dans le sélecteur ou avec Toggle Coverage Painting l’écrivait dans settings.json — un fichier sous contrôle de version dans beaucoup de projets, réécrit par un bouton fait pour être pressé deux fois par minute. Le choix vit désormais le temps de la session, et un mode que vous avez écrit dans vos réglages l’emporte toujours à l’ouverture de la fenêtre.

Ajouté

• Run Mutation Tests Here. La couverture dit qu’une ligne a été exécutée ; un outil de mutation dit si un test remarquerait qu’elle est fausse. La fonction où se trouve le curseur — ou les lignes sélectionnées, ou le fichier — est ce que l’outil de mutation du dossier est chargé de muter, et son rapport est chargé à côté de la couverture à l’écran : Stryker.NET pour C#, StrykerJS pour JavaScript et TypeScript, PIT avec Maven pour Java. L’exécution de mutation d’un projet prend une heure ; celle d’une fonction, une minute.

Ajouté

• Run Mutation Tests Here. La couverture dit qu’une ligne a été exécutée ; un outil de mutation dit si un test remarquerait qu’elle est fausse. La fonction où se trouve le curseur — ou les lignes sélectionnées, ou le fichier — est ce que l’outil de mutation du dossier est chargé de muter, et son rapport est chargé à côté de la couverture à l’écran : Stryker.NET pour C#, StrykerJS pour JavaScript et TypeScript, PIT avec Maven pour Java. L’exécution de mutation d’un projet prend une heure ; celle d’une fonction, une minute.

Ajouté

• Run App with Coverage… mesure ce qu’une personne atteint, et pas seulement ce que font les tests : l’application .NET du dossier est démarrée sous dotnet-coverage de Microsoft, dans une console à elle, et tourne jusqu’à ce qu’on la ferme. Ce qui a été parcouru est ensuite chargé comme n’importe quelle exécution et, dans une session de couverture, ajouté à ce que les tests ont exécuté. Nécessite dotnet tool install --global dotnet-coverage.

Ajouté

• Run App with Coverage… mesure ce qu’une personne atteint, et pas seulement ce que font les tests : l’application .NET du dossier est démarrée sous dotnet-coverage de Microsoft, dans une console à elle, et tourne jusqu’à ce qu’on la ferme. Ce qui a été parcouru est ensuite chargé comme n’importe quelle exécution et, dans une session de couverture, ajouté à ce que les tests ont exécuté. Nécessite dotnet tool install --global dotnet-coverage.

Ajouté

• Une référence CI tirée d’un artefact zip. GitHub et GitLab publient un artefact sous forme d’archive. Là où baseline.report en nomme un — une URL, ou un zip sur le disque —, il est ouvert et le rapport qu’il contient conservé : le membre nommé après le # (ci/artifact.zip#coverage/lcov.info), sinon l’unique fichier de l’archive, sinon son unique fichier qui ressemble à un rapport.

Ajouté

• Artefacts zip de GitHub et de GitLab. La CI publie un artefact, et un artefact est une archive. Un zip récupéré est désormais ouvert et le rapport qu’il contient conservé — le membre nommé après le # de l’URL (…/zip#coverage/lcov.info), sinon l’unique fichier de l’archive, sinon son unique fichier qui ressemble à un rapport. Pour une URL dans coverageFile.paths, pour baseline.report, et pour une référence qui est un zip sur le disque.

Corrigé

• Les fichiers d’une référence Cobertura n’étaient pas trouvés sous le <source> propre au rapport. La comparaison disait 0 file(s) moved à côté d’un total qui avait bougé. La racine que nomme le rapport est désormais utilisée, comme pour un rapport chargé.

Ajouté

• Le nouveau code par auteur et par date. Le nouveau code, c’était les lignes modifiées par rapport à une ref git. Deux réglages demandent ce qu’une ref ne peut pas dire : fuciniCoverage.gitDiff.author — les lignes qu’une personne a écrites — et fuciniCoverage.gitDiff.since — les lignes écrites depuis un jour donné. Les deux sont lus dans git blame et s’appliquent à la couverture du diff et au seuil sur le nouveau code.

Ajouté

• Le nouveau code par auteur et par date. Le nouveau code, c’était les lignes modifiées par rapport à une ref git. Deux réglages demandent ce qu’une ref ne peut pas dire : fuciniCoverage.gitDiff.author — les lignes qu’une personne a écrites — et fuciniCoverage.gitDiff.since — les lignes écrites depuis un jour donné. Les deux sont lus dans git blame et s’appliquent à la couverture du diff et au seuil sur le nouveau code.

Ajouté

• Run This Test with Coverage lit Go et Rust. Dans un fichier Go, le func TestXxx du curseur s’exécute seul, dans son propre package et par son nom exact — go test ./pkg/calc -run "^TestTotal$". Dans un fichier Rust, la fonction #[test] s’exécute par son chemin dans le crate, --exact ; dans un mod, les tests de ce module ; un test d’intégration sous tests/, dans son propre binaire.

Ajouté

• Run This Test with Coverage lit Go et Rust. Dans un fichier Go, le func TestXxx du curseur s’exécute seul, dans son propre package et par son nom exact — go test ./pkg/calc -run "^TestTotal$". Dans un fichier Rust, la fonction #[test] s’exécute par son chemin dans le crate, --exact ; dans un mod, les tests de ce module ; un test d’intégration sous tests/, dans son propre binaire.

Ajouté

• La couverture de conditions de GCC 14, ligne par ligne. -fcondition-coverage était lu comme deux compteurs par fichier ; chaque condition est désormais marquée sur sa ligne et nommée dans l’info-bulle — condition 1 jamais vraie, condition 0 jamais dans un sens ni dans l’autre — à partir du JSON de gcov et de son listing texte. threshold.conditions en fait un seuil, Copy Coverage Summary a une colonne Conditions, badge.metric accepte conditions, et la recherche accepte conditions < 80.

Corrigé

• Le chiffre de branches d’une fonction comptait aussi les issues de ses conditions. branches 8/12 là où l’outil disait 4 sur 6. Les conditions en sont désormais exclues, comme elles le sont des chiffres du fichier et de l’exécution.

Ajouté

• La couverture de conditions de GCC 14, ligne par ligne. -fcondition-coverage était lu comme deux compteurs par fichier ; chaque condition est désormais marquée sur sa ligne et nommée dans l’info-bulle — condition 1 jamais vraie, condition 0 jamais dans un sens ni dans l’autre — à partir du JSON de gcov et de son listing texte. threshold.conditions en fait un seuil, Copy Coverage Summary a une colonne Conditions, badge.metric accepte conditions, et la recherche accepte conditions < 80.

Corrigé

• Le chiffre de branches d’une fonction comptait aussi les issues de ses conditions. branches 8/12 là où l’outil disait 4 sur 6. Les conditions en sont désormais exclues, comme elles le sont des chiffres du fichier et de l’exécution.

Ajouté

• La vue Coverage suit l’éditeur. Le fichier que vous regardez est mis en évidence dans l’arbre, les dossiers au-dessus de lui sont ouverts et sa ligne est amenée à l’écran. fuciniCoverage.coverageView.followActiveEditor le désactive.

Ajouté

• La vue Coverage suit l’éditeur. Le fichier que vous regardez est mis en évidence dans l’arbre, les dossiers au-dessus de lui sont ouverts et sa ligne est amenée à l’écran. fuciniCoverage.coverageView.followActiveEditor le désactive.

Ajouté

• Marqueurs d’exclusion pour les seules branches, et marqueurs gcovr. LCOV_EXCL_BR_LINE et LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP retirent du décompte les branches de leurs lignes et y laissent les lignes ; LCOV_EXCL_EXCEPTION_BR_LINE ne retire que les bras qu’une exception atteint. Chaque marqueur est lu aussi sous les préfixes de gcovr : GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE et les autres.

Corrigé

• Un rapport .NET n’affichait aucune couverture de branches. Coverlet et dotnet-coverage écrivent l’attribut branch d’une ligne Cobertura sous la forme True, et seul le true en minuscules était lu — si bien que chaque décision d’un tel rapport était perdue. Les deux graphies sont lues désormais. Les chiffres bougent : la couverture de branches d’un projet .NET apparaît là où il n’y en avait pas, et son score avec elle.
• Un rapport Cobertura fusionné à partir de plusieurs arborescences ne trouvait que les fichiers de la première. Un tel rapport nomme un <source> par arborescence ; chacun est désormais essayé, dans l’ordre du rapport.

Ajouté

• Marqueurs d’exclusion pour les seules branches, et marqueurs gcovr. LCOV_EXCL_BR_LINE et LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP retirent du décompte les branches de leurs lignes et y laissent les lignes ; LCOV_EXCL_EXCEPTION_BR_LINE ne retire que les bras qu’une exception atteint. Chaque marqueur est lu aussi sous les préfixes de gcovr : GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE et les autres.

Corrigé

• Un rapport .NET n’affichait aucune couverture de branches. Coverlet et dotnet-coverage écrivent l’attribut branch d’une ligne Cobertura sous la forme True, et seul le true en minuscules était lu — si bien que chaque décision d’un tel rapport était perdue. Les deux graphies sont lues désormais. Les chiffres bougent : la couverture de branches d’un projet .NET apparaît là où il n’y en avait pas, et son score avec elle.
• Un rapport Cobertura fusionné à partir de plusieurs arborescences ne trouvait que les fichiers de la première. Un tel rapport nomme un <source> par arborescence ; chacun est désormais essayé, dans l’ordre du rapport.

Ajouté

• Show Minimal Test Set… trouve le plus petit nombre de tests qui exécutent encore chaque ligne que la suite exécute, et liste en dessous les tests qui n’ajoutent aucune ligne à eux seuls. Pour l’exécution rapide avant un commit, et pour quiconque élague la suite — avec ce rappel : redondant par les lignes n’est pas redondant par ce qu’un test vérifie.

Ajouté

• Show Minimal Test Set… trouve le plus petit nombre de tests qui exécutent encore chaque ligne que la suite exécute, et liste en dessous les tests qui n’ajoutent aucune ligne à eux seuls. Pour l’exécution rapide avant un commit, et pour quiconque élague la suite — avec ce rappel : redondant par les lignes n’est pas redondant par ce qu’un test vérifie.

Ajouté

• Exclusions justifiées. Le code retiré du décompte là où il est écrit peut dire pourquoi — // LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] — et les raisons sont rapportées : Export Coverage Report… liste les exclusions et leurs justifications en Markdown et en CSV. Avec fuciniCoverage.exclusions.requireReason, une exclusion qui ne donne aucune raison est un avertissement à sa ligne et fait échouer Check Coverage Thresholds.

Ajouté

• Exclusions justifiées. Le code retiré du décompte là où il est écrit peut dire pourquoi — // LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] — et les raisons sont rapportées : Export Coverage Report… liste les exclusions et leurs justifications en Markdown et en CSV. Avec fuciniCoverage.exclusions.requireReason, une exclusion qui ne donne aucune raison est un avertissement à sa ligne et fait échouer Check Coverage Thresholds.

Ajouté

• Un seuil sur le nouveau code, à côté des seuils sur l’exécution entière. fuciniCoverage.threshold.newCode est la couverture de lignes minimale, en pour cent, des lignes modifiées par rapport à gitDiff.baseRef. Check Coverage Thresholds le fait échouer dans une phrase à part — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) — et l’exécution entière reste à l’écran.
• Show Indirect Coverage Changes… liste les lignes dont la couverture a bougé alors que personne ne les a modifiées — du code qui a cessé de s’exécuter parce qu’un test a disparu, ou parce qu’une branche en amont retourne désormais plus tôt. Par rapport à la référence CI là où baseline.report en nomme une, sinon par rapport à l’exécution précédente.

Ajouté

• Un seuil sur le nouveau code, à côté des seuils sur l’exécution entière. fuciniCoverage.threshold.newCode est la couverture de lignes minimale, en pour cent, des lignes modifiées par rapport à gitDiff.baseRef. Check Coverage Thresholds le fait échouer dans une phrase à part — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) — et l’exécution entière reste à l’écran.
• Show Indirect Coverage Changes… liste les lignes dont la couverture a bougé alors que personne ne les a modifiées — du code qui a cessé de s’exécuter parce qu’un test a disparu, ou parce qu’une branche en amont retourne désormais plus tôt. Par rapport à la référence CI là où baseline.report en nomme une, sinon par rapport à l’exécution précédente.

Ajouté

• Run Tests Affected by My Changes… liste les tests qui ont exécuté une ligne que l’arbre de travail modifie par rapport à fuciniCoverage.testImpact.baseRef (HEAD par défaut), celui qui a exécuté la plus grande part de la modification en premier. Choisir un test l’ouvre ; là où les rapports proviennent d’une exécution par test (testRun.perTest), la première entrée n’exécute que ces tests.

Corrigé

• testRun.skipWhenTestsFail tient au-delà de l’exécution. Les rapports qu’une exécution rouge avait écrits restaient sur le disque, où l’observateur les chargeait un instant plus tard. Ils sont désormais supprimés.
• La copie qu’un logger TRX fait d’un rapport de couverture n’est jamais prise pour un fichier de trace.

Ajouté

• Run Tests Affected by My Changes… liste les tests qui ont exécuté une ligne que l’arbre de travail modifie par rapport à fuciniCoverage.testImpact.baseRef (HEAD par défaut), celui qui a exécuté la plus grande part de la modification en premier. Choisir un test l’ouvre ; là où les rapports proviennent d’une exécution par test (testRun.perTest), la première entrée n’exécute que ces tests.

Corrigé

• testRun.skipWhenTestsFail tient au-delà de l’exécution. Les rapports qu’une exécution rouge avait écrits restaient sur le disque, où l’observateur les chargeait un instant plus tard. Ils sont désormais supprimés.
• La copie qu’un logger TRX fait d’un rapport de couverture n’est jamais prise pour un fichier de trace.

Ajouté

• Réussite ou échec sur les marques. Une ligne qu’un test en échec a exécutée reçoit une barre rouge à son début, et son info-bulle nomme les tests en échec ; Show Tests That Ran This Line dit lesquels des tests ont échoué. Il faut un rapport qui dise quels tests ont exécuté une ligne, et le fichier de résultats du lanceur de tests — TRX ou JUnit XML — dans le dossier du rapport ou nommé dans fuciniCoverage.testResults.paths. Run Tests with Coverage en demande désormais un à dotnet test.
• La couverture de code de Visual Studio lui-même, chargée. Le fichier .coverage qu’écrit Analyze Code Coverage de Visual Studio est converti avec dotnet-coverage et chargé de lui-même : Coverage Studio s’appuie sur le collecteur intégré au lieu de lui faire concurrence.

Ajouté

• Réussite ou échec sur les marques. Une ligne qu’un test en échec a exécutée reçoit une barre rouge à son début, et son info-bulle nomme les tests en échec ; Show Tests That Ran This Line dit lesquels des tests ont échoué. Il faut un rapport qui dise quels tests ont exécuté une ligne, et le fichier de résultats du lanceur de tests — TRX ou JUnit XML — dans le dossier du rapport ou nommé dans fuciniCoverage.testResults.paths. Run Tests with Coverage en demande désormais un à dotnet test.

Corrigé

• Le champ de recherche garde sa requête, et son focus, quand la couverture se recharge. Chaque rechargement le vidait, souvent pendant que la requête était encore en cours de saisie. Une requête telle que < 80% garde aussi les points chauds de risque auxquels elle correspond.
• Une session de couverture ne compte plus deux fois la même exécution. Chaque rechargement de rapports inchangés les ajoutait de nouveau, et chaque compteur de passages doublait. Une session garde désormais chaque jeu de rapports une seule fois.
• La référence CI ne retarde plus un chargement. Le chargement est affiché d’abord et la comparaison suit. La référence est préparée une seule fois et conservée tant que son rapport et les réglages restent les mêmes, et quand l’URL est injoignable, la copie récupérée auparavant est utilisée.
• « Depuis la dernière exécution » survit à un rechargement de rapports inchangés. Un changement de réglage ou une actualisation faisait de l’exécution à l’écran sa propre dernière exécution, et tous les changements depuis l’exécution précédente disparaissaient. Une telle relecture n’est plus conservée non plus dans l’historique.
• Un chargement à la fois. Deux rechargements demandés ensemble s’exécutaient côte à côte, et le plus lent l’emportait. Les rechargements demandés pendant un chargement deviennent désormais un seul chargement après lui.
• Une référence CI via HTTP est récupérée comme dans VS Code. Un seul client, la dernière copie conservée pour le cas où le serveur est injoignable, et remote.headers envoyés uniquement à l’adresse pour laquelle ils ont été écrits — jamais en HTTP non chiffré.
• Une commande dont le travail échoue le dit. Un échec dans une commande ou un minuteur était avalé ; c’est désormais une ligne dans la fenêtre Sortie.
• Moins de travail sur le thread d’interface. Les observateurs de fichiers sont créés en arrière-plan, les entrées de la Liste d’erreurs sont calculées une fois par chargement, et le journal est écrit par salves plutôt que ligne par ligne.
• Deux fenêtres Visual Studio n’endommagent plus l’historique des exécutions. Son index est remplacé en une seule étape sous un verrou que les deux partagent, et reconstruit à partir des exécutions quand il est perdu.
• Run Native Project with Coverage compile pour la plateforme propre au projet, et prend llvm-cov et llvm-profdata dans le LLVM du compilateur, comme une paire.
• Les couleurs d’avertissement, d’erreur et de réussite de la fenêtre Coverage suivent un thème clair aussi bien qu’un thème sombre.
• Un fichier de paramètres ouvert avec des modifications non enregistrées n’est pas écrasé. La page des réglages dit de l’enregistrer d’abord.

Modifié

• Un fichier de couverture que vous choisissez, et le rapport qu’écrit une exécution de tests, sont mémorisés pour vous au lieu d’être écrits dans .vscode/settings.json. Ce fichier est souvent commité, si bien qu’une exécution de tests laissait dans le dépôt une modification que personne n’avait demandée. Les chemins déjà présents dans coverageFile.paths continuent de fonctionner.

Corrigé

• Le champ de recherche garde sa requête, et son focus, quand la couverture se recharge. Chaque rechargement le vidait, souvent pendant que la requête était encore en cours de saisie. Une requête telle que < 80% garde aussi les points chauds de risque auxquels elle correspond.
• Une session de couverture ne compte plus deux fois la même exécution. Chaque rechargement de rapports inchangés les ajoutait de nouveau, et chaque compteur de passages doublait. Une session garde désormais chaque jeu de rapports une seule fois.
• La référence CI ne retarde plus un chargement. Le chargement est affiché d’abord et la comparaison suit. La référence est préparée une seule fois et conservée tant que son rapport et les réglages restent les mêmes, et quand l’URL est injoignable, la copie récupérée auparavant est utilisée.
• La vérification des fichiers de rapport modifiés s’exécute une passe à la fois. Sur un lecteur réseau lent, deux passes voyaient la même modification, et la couverture était chargée deux fois.
• « Depuis la dernière exécution » survit à un rechargement de rapports inchangés. Un changement de réglage ou une actualisation faisait de l’exécution à l’écran sa propre dernière exécution, et tous les changements depuis l’exécution précédente disparaissaient. Une telle relecture n’est plus conservée non plus dans l’historique.

Modifié

• Un fichier de couverture que vous choisissez, et le rapport qu’écrit une exécution de tests, sont mémorisés pour vous au lieu d’être écrits dans .vscode/settings.json. Ce fichier est souvent commité, si bien qu’une exécution de tests laissait dans le dépôt une modification que personne n’avait demandée. Les chemins déjà présents dans coverageFile.paths continuent de fonctionner.

Corrigé

• Une solution .NET avec deux projets de test ou plus ne perd plus la couverture de tous ses projets sauf un. dotnet test écrivait un rapport par projet et tous étaient déplacés sur le même coverage/coverage.cobertura.xml, si bien que seul le dernier était chargé. Un tel dossier exécute désormais dotnet test une fois par projet de test, chaque rapport va dans coverage/<Project>/, et l’exécution d’un seul projet ne remplace que le rapport de ce projet.
• Enregistrer plusieurs fichiers à la fois lance les tests de chaque fichier enregistré. Avec testRun.onSave, seuls les tests du dernier fichier s’exécutaient ; les enregistrements qui arrivent pendant une exécution sont conservés et exécutés ensemble après elle.
• Run This Test with Coverage et les exécutions par test exécutent exactement ce qu’elles nomment. Le filtre .NET cherchait par sous-chaîne : Total exécutait aussi TotalTax. Un test s’exécute désormais par son nom exact, une classe par son nom suivi d’un point, et un test dans une classe imbriquée est trouvé (Outer+Inner).
• Un test jest ou vitest dont le titre contient (, + ou $ s’exécute. Le titre était passé à -t, qui lit une expression régulière, si bien qu’un tel test ne correspondait à rien et que rien ne s’exécutait.
• Run This Test with Coverage lit les fichiers de test VB et F#. <Fact> au-dessus de Public Sub, et [<Fact>] au-dessus de let ou de member, n’étaient jamais reconnus.
• Annuler une exécution de tests met fin à tous les processus qu’elle a démarrés. Seul le shell était arrêté, et dotnet test continuait derrière lui. Fermer Visual Studio annule aussi l’exécution.
• Taper pendant une exécution lancée par un enregistrement ne décale plus les marques. Elles sont épinglées au texte que l’exécution a mesuré.
• Une solution sur un partage réseau y exécute ses tests. L’exécution démarrait dans C:\Windows, car l’interpréteur de commandes n’accepte pas un chemin \\server\share comme dossier.

Corrigé

• Une solution .NET avec deux projets de test ou plus ne perd plus la couverture de tous ses projets sauf un. dotnet test écrivait un rapport par projet et tous étaient déplacés sur le même coverage/coverage.cobertura.xml, si bien que seul le dernier était chargé. Un tel dossier exécute désormais dotnet test une fois par projet de test, chaque rapport va dans coverage/<Project>/, et l’exécution d’un seul projet ne remplace que le rapport de ce projet.
• Enregistrer plusieurs fichiers à la fois lance les tests de chaque fichier enregistré. Avec testRun.onSave, seuls les tests du dernier fichier s’exécutaient ; les enregistrements qui arrivent pendant une exécution sont conservés et exécutés ensemble après elle.
• Run This Test with Coverage et les exécutions par test exécutent exactement ce qu’elles nomment. Le filtre .NET cherchait par sous-chaîne : Total exécutait aussi TotalTax. Un test s’exécute désormais par son nom exact, une classe par son nom suivi d’un point, et un test dans une classe imbriquée est trouvé (Outer+Inner).
• Un test jest ou vitest dont le titre contient (, + ou $ s’exécute. Le titre était passé à -t, qui lit une expression régulière, si bien qu’un tel test ne correspondait à rien et que rien ne s’exécutait.
• Un titre de test contenant des guillemets arrive entier au terminal. Une commande avec \" entre guillemets se disloquait au premier.
• Run This Test with Coverage lit les fichiers de test VB et F#. <Fact> au-dessus de Public Sub, et [<Fact>] au-dessus de let ou de member, n’étaient jamais reconnus.
• Une tâche de test qui se termine sans démarrer de processus ne laisse plus Run Tests with Coverage attendre indéfiniment. La commande se termine et dit que l’exécution n’a rien écrit.

Ajouté

• Quels tests ont exécuté cette ligne. Là où le rapport l’enregistre — coverage.py avec --show-contexts, les méthodes suivies d’OpenCover, un fichier de trace lcov écrit par test —, le CodeLens d’une fonction indique combien de tests l’ont exécutée, et Show Tests That Ran This Line les liste, les plus actifs d’abord, et ouvre celui que vous choisissez. Pour une exécution dotnet test, testRun.perTest lance les tests une classe à la fois, afin que chaque rapport dise quelle classe l’a écrit.
• La couverture après chaque enregistrement. Avec testRun.onSave, enregistrer un fichier source lance les tests qui le couvrent, avec couverture, et la marge suit. Dans une solution .NET, seuls les projets de test qui référencent le projet du fichier enregistré s’exécutent ; plusieurs enregistrements à la suite font une seule exécution.
• Run This Test with Coverage. Le curseur dans une méthode de test, une classe de test ou un describe, ou dans un fichier de test, une seule commande exécute exactement cela avec couverture — dotnet test --filter, jest/vitest -t ou un identifiant de nœud pytest — et charge ce qu’elle a écrit. Le test est lu dans le texte, donc cela fonctionne pour C#, VB, F#, JavaScript, TypeScript et Python sans service de langage.
• Exclude from Coverage, et deux filtres .NET. Un clic droit sur une ligne de l’arbre de couverture, ou Exclude This File from Coverage sur le fichier ouvert, ajoute le fichier ou le dossier à fuciniCoverage.ignore, et il sort de chaque total. ignore.namespaces écarte les fichiers d’un espace de noms (*.Migrations), et ignore.attributes la classe, la méthode ou la propriété placée sous un attribut — ExcludeFromCodeCoverage par défaut, que ni OpenCover, ni dotCover, ni un lcov converti ne respectent.
• Exclude Selection from Coverage. Sélectionnez des lignes et choisissez l’action dans l’ampoule ou le menu contextuel de l’éditeur : au-dessus d’une classe, d’une méthode ou d’une propriété .NET, elle écrit [ExcludeFromCodeCoverage] — sous la forme courte si le fichier importe déjà System.Diagnostics.CodeAnalysis —, et ailleurs LCOV_EXCL_LINE ou une paire LCOV_EXCL_START/STOP dans le commentaire propre au langage. Un marqueur déjà présent n’est pas doublé.
• Espaces de noms, classes et méthodes. Pour un rapport .NET qui nomme ses classes — Cobertura, Coverlet, OpenCover —, une liste Folders / Namespaces présente la même exécution par espace de noms, classe et méthode, avec le même tri et le même filtre ; une ligne de méthode ouvre le fichier sur la méthode. Les types générés par le compilateur, comme <>c et les machines à états async, sont repliés dans la classe pour laquelle ils ont été générés.
• Un champ de recherche au-dessus de l’arbre de couverture. Tapez des mots pour garder les lignes dont le nom ou le chemin les contient tous, ou une comparaison — < 80%, lines >= 90, branches = 0 — pour garder les lignes dont le chiffre la satisfait ; les deux ensemble exigent les deux. Les lignes de méthode et les points chauds de risque sont aussi parcourus ; Escape efface.
• Run Native Project with Coverage. Le projet de démarrage C++, depuis le menu Tools : un projet ClangCL est reconstruit avec l’instrumentation de couverture de clang dans coverage/native/, exécuté, et son rapport chargé ; tout autre ensemble d’outils s’exécute sous OpenCppCoverage là où il est installé, et quand aucun des deux n’est possible, une phrase indique quoi installer.
• Sessions de couverture et tendance. Start Coverage Session, et chaque exécution chargée ensuite s’ajoute aux précédentes — lignes, branches et fonctions de même : ce que l’une d’elles a exécuté est couvert —, si bien que les tests unitaires, les tests d’intégration et un parcours de l’application montrent ce qu’ils ont atteint ensemble. Sous la barre d’outils, la couverture de lignes de l’historique enregistré est tracée en tendance, un point par exécution.
• Compare Two History Runs, comme dans VS Code : choisissez deux exécutions conservées, et les fichiers qui ont bougé entre elles sont listés de la plus ancienne à la plus récente, quel que soit l’ordre du choix.
• Compare with CI Baseline. baseline.report désigne le rapport que publie la build de votre branche principale — une URL, récupérée avec remote.headers, ou un fichier téléchargé —, et chaque chargement est mesuré par rapport à lui : la carte de la barre d’état dit où en est cette exécution, et Compare with CI Baseline liste les fichiers qui ont bougé. La référence passe par la même liste d’exclusions que l’exécution, pour que les totaux se comparent à égalité.
• Où les trouver. Les nouvelles commandes sont sous Tools > Coverage Studio et dans le menu contextuel de l’éditeur ; Show Tests That Ran This Line est aussi Ctrl+Shift+U, T, et Exclude Selection from Coverage est une action de l’ampoule.

Corrigé

• Le rapport d’une exécution de tests ne porte plus votre nom d’utilisateur et de machine. Le collecteur Code Coverage de Microsoft nomme son rapport <user>_<machine>_<stamp>.cobertura.xml, et ce nom figurait dans l’arbre et sur chaque capture d’écran ; le rapport est désormais renommé en coverage.cobertura.xml avant d’être chargé.
• Un fichier généré était dit écarté par fuciniCoverage.ignore. Chaque fichier écarté est maintenant compté sous le paramètre qui l’a écarté — ignore, ignore.generated ou ignore.namespaces —, de sorte que le nom affiché est celui à modifier.
• Un fichier de trace lcov écrit par test est lu comme un enregistrement par fichier, ses sections de test additionnées, comme VS Code le lit ; auparavant, l’enregistrement de chaque test était un fichier à part.
• Le journal dit ce qu’un parseur a laissé de côté. Les fichiers dans lesquels un parseur n’a rien trouvé à instrumenter (FUCINI_PARSE_030) et le compte rendu qu’un rapport fait de ses propres lacunes (FUCINI_PARSE_031, le MissingPdb d’OpenCover) sont écrits dans le journal, comme VS Code les écrit.
• Un en-tête de macros ne figure plus à 100 % dans l’arbre. llvm-cov et gcov imputent les utilisations d’une macro aux lignes qui la définissent ; les branches et fonctions situées sur des lignes exclues partent désormais avec ces lignes, et un fichier sans plus rien de mesurable est retiré de l’exécution et nommé dans la sortie (FUCINI_EXCLUDE_001).
• Cinq rapports refusés comme format non pris en charge sont reconnus. Le XML JaCoCo de Kover, un rapport Stryker.NET, un rapport NCover, un ancien resultset SimpleCov et un rapport SonarQube de nombreux fichiers vides sont maintenant reconnus à ce qu’ils portent en tête. Un rapport Clover ou SonarQube dont les chemins contiennent le mot cobertura n’est plus lu comme du Cobertura.
• Des chiffres qui concordent avec les outils qui les ont écrits. Le chiffre de branches d’une build MC/DC correspond à llvm-cov report ; les branches d’exception de LCOV 2 (BRDA:12,e0,1,3) comptent ; une fonction llvm-cov n’est déclarée que dans le fichier qui la définit ; un bloc Go listé par deux binaires de test additionne ses compteurs ; une décision Cobertura signalée par deux classes et une ligne JaCoCo listée deux fois gardent toutes leurs branches, une seule fois.
• De plus petites. Un fichier de trace coupé en cours d’écriture ne perd plus de fichier ; gcov -t sur plusieurs fichiers .gcda donne un fichier chacun, les instanciations de template sont lues une seule fois et les compteurs comme 1.20k de gcov -H sont conservés ; les fichiers GNATcoverage ne sont plus tous signalés comme modifiés depuis leur couverture ; un mutant Stryker en attente ou une exécution PIT interrompue ne comptent plus contre le score.
• Une modification manuelle du fichier de paramètres est appliquée dès son enregistrement, comme VS Code applique un changement de paramètre.

Ajouté

• Quels tests ont exécuté cette ligne. Là où le rapport l’enregistre — coverage.py avec --show-contexts, les méthodes suivies d’OpenCover, un fichier de trace lcov écrit par test —, le CodeLens d’une fonction indique combien de tests l’ont exécutée, et Show Tests That Ran This Line les liste, les plus actifs d’abord, et ouvre celui que vous choisissez. Pour une exécution dotnet test, testRun.perTest lance les tests une classe à la fois, afin que chaque rapport dise quelle classe l’a écrit.
• La couverture après chaque enregistrement. Avec testRun.onSave, enregistrer un fichier source lance les tests qui le couvrent, avec couverture, et la marge suit. Dans une solution .NET, seuls les projets de test qui référencent le projet du fichier enregistré s’exécutent ; plusieurs enregistrements à la suite font une seule exécution.
• Run This Test with Coverage. Le curseur dans une méthode de test, une classe de test ou un describe, ou dans un fichier de test, une seule commande exécute exactement cela avec couverture — dotnet test --filter, jest/vitest -t ou un identifiant de nœud pytest — et charge ce qu’elle a écrit. Le test est lu dans le texte, donc cela fonctionne pour C#, VB, F#, JavaScript, TypeScript et Python sans service de langage.
• Exclude from Coverage, et deux filtres .NET. Un clic droit sur une ligne de l’arbre de couverture, ou Exclude This File from Coverage sur le fichier ouvert, ajoute le fichier ou le dossier à fuciniCoverage.ignore, et il sort de chaque total. ignore.namespaces écarte les fichiers d’un espace de noms (*.Migrations), et ignore.attributes la classe, la méthode ou la propriété placée sous un attribut — ExcludeFromCodeCoverage par défaut, que ni OpenCover, ni dotCover, ni un lcov converti ne respectent.
• Exclude Selection from Coverage. Sélectionnez des lignes et choisissez l’action dans l’ampoule ou le menu contextuel de l’éditeur : au-dessus d’une classe, d’une méthode ou d’une propriété .NET, elle écrit [ExcludeFromCodeCoverage] — sous la forme courte si le fichier importe déjà System.Diagnostics.CodeAnalysis —, et ailleurs LCOV_EXCL_LINE ou une paire LCOV_EXCL_START/STOP dans le commentaire propre au langage. Un marqueur déjà présent n’est pas doublé.
• Espaces de noms, classes et méthodes. Pour un rapport .NET qui nomme ses classes — Cobertura, Coverlet, OpenCover —, une liste Folders / Namespaces présente la même exécution par espace de noms, classe et méthode, avec le même tri et le même filtre ; une ligne de méthode ouvre le fichier sur la méthode. Les types générés par le compilateur, comme <>c et les machines à états async, sont repliés dans la classe pour laquelle ils ont été générés.
• Un champ de recherche au-dessus de l’arbre de couverture. Tapez des mots pour garder les lignes dont le nom ou le chemin les contient tous, ou une comparaison — < 80%, lines >= 90, branches = 0 — pour garder les lignes dont le chiffre la satisfait ; les deux ensemble exigent les deux. Les lignes de méthode et les points chauds de risque sont aussi parcourus ; Escape efface.
• Sessions de couverture et tendance. Start Coverage Session, et chaque exécution chargée ensuite s’ajoute aux précédentes — lignes, branches et fonctions de même : ce que l’une d’elles a exécuté est couvert —, si bien que les tests unitaires, les tests d’intégration et un parcours de l’application montrent ce qu’ils ont atteint ensemble. Sous la barre d’outils, la couverture de lignes de l’historique enregistré est tracée en tendance, un point par exécution.
• Compare with CI Baseline. baseline.report désigne le rapport que publie la build de votre branche principale — une URL, récupérée avec remote.headers, ou un fichier téléchargé —, et chaque chargement est mesuré par rapport à lui : la carte de la barre d’état dit où en est cette exécution, et Compare with CI Baseline liste les fichiers qui ont bougé. La référence passe par la même liste d’exclusions que l’exécution, pour que les totaux se comparent à égalité.

Corrigé

• Le rapport d’une exécution de tests ne porte plus votre nom d’utilisateur et de machine. Le collecteur Code Coverage de Microsoft nomme son rapport <user>_<machine>_<stamp>.cobertura.xml, et ce nom figurait dans l’arbre et sur chaque capture d’écran ; le rapport est désormais renommé en coverage.cobertura.xml avant d’être chargé.
• Une exécution de tests échouait sous Windows quand le terminal est PowerShell. Les guillemets autour de Code Coverage;Format=cobertura se perdaient en route vers pwsh, qui lisait le ; comme la fin de la commande ; la recette est maintenant remise au terminal mot par mot et mise entre guillemets pour le shell qu’il lance.
• Un fichier généré était dit écarté par fuciniCoverage.ignore. Chaque fichier écarté est maintenant compté sous le paramètre qui l’a écarté — ignore, ignore.generated ou ignore.namespaces —, de sorte que le nom affiché est celui à modifier.
• Un en-tête de macros ne figure plus à 100 % dans l’arbre. llvm-cov et gcov imputent les utilisations d’une macro aux lignes qui la définissent ; les branches et fonctions situées sur des lignes exclues partent désormais avec ces lignes, et un fichier sans plus rien de mesurable est retiré de l’exécution et nommé dans la sortie (FUCINI_EXCLUDE_001).
• Cinq rapports refusés comme format non pris en charge sont reconnus. Le XML JaCoCo de Kover, un rapport Stryker.NET, un rapport NCover, un ancien resultset SimpleCov et un rapport SonarQube de nombreux fichiers vides sont maintenant reconnus à ce qu’ils portent en tête. Un rapport Clover ou SonarQube dont les chemins contiennent le mot cobertura n’est plus lu comme du Cobertura.
• Des chiffres qui concordent avec les outils qui les ont écrits. Le chiffre de branches d’une build MC/DC correspond à llvm-cov report ; les branches d’exception de LCOV 2 (BRDA:12,e0,1,3) comptent ; une fonction llvm-cov n’est déclarée que dans le fichier qui la définit ; un bloc Go listé par deux binaires de test additionne ses compteurs ; une décision Cobertura signalée par deux classes et une ligne JaCoCo listée deux fois gardent toutes leurs branches, une seule fois.
• De plus petites. Un fichier de trace coupé en cours d’écriture ne perd plus de fichier ; gcov -t sur plusieurs fichiers .gcda donne un fichier chacun, les instanciations de template sont lues une seule fois et les compteurs comme 1.20k de gcov -H sont conservés ; les fichiers GNATcoverage ne sont plus tous signalés comme modifiés depuis leur couverture ; un mutant Stryker en attente ou une exécution PIT interrompue ne comptent plus contre le score.

Modifié

• Plus de FUCINI_ENCODING_001 à chaque chargement. Un rapport sans marque d’ordre des octets est lu en UTF-8, comme tout outil l’écrit, sans note pour le dire.

Ajouté

• Une entrée relative avec un joker est recherchée à n’importe quelle profondeur. *.lcov.info dans coverageFile.paths trouve le fichier où qu’il soit sous le dossier de base, comme VS Code l’a toujours lu ; une entrée enracinée — ${workspaceFolder}/build/coverage-merged/*.lcov.info, ** pour n’importe quelle profondeur — regarde exactement là où elle le dit, comme avant.
• Surveillé là où le rapport apparaîtra. La surveillance couvre les dossiers que nomment les réglages, qu’un rapport s’y trouve déjà ou non : le dossier d’un fichier enraciné, les dossiers avant un joker — avec tout ce qui se trouve en dessous quand le motif descend dans les sous-dossiers — et le dossier de base pour un joker relatif. Un rapport qu’un build y écrit se charge de lui-même ; une écriture dans tout autre fichier de ces dossiers est ignorée.

Corrigé

• Un rapport JSON llvm-cov était refusé comme format non pris en charge. Le format est reconnu d’après les 4096 premiers caractères, et llvm-cov écrit son marqueur "type": "llvm.coverage.json.export" tout à la fin ; un export dont le premier enregistrement de fichier porte de nombreuses branches et des expansions de macros imbriquées n’avait rien d’autre de reconnaissable dans ce début. Un tel rapport est désormais reconnu à son ouverture, {"data":[{"files":[, qu’aucun autre format n’a.
• De même pour gcov --json-format. gcov écrit les fonctions d’un fichier avant ses lignes, et un fichier d’une douzaine de fonctions n’a pas non plus d’entrée de ligne dans le début inspecté ; la clé gcc_version propre au document l’identifie désormais.

Ajouté

• Un joker dans une entrée absolue de coverageFile.paths. ${workspaceFolder}/build/coverage-merged/*.lcov.info charge chaque fichier de ce genre dans ce dossier, et ** vaut pour n’importe quelle profondeur : les dossiers avant le premier joker sont parcourus, le reste est le motif sous eux, comme l’édition Visual Studio a toujours lu une telle entrée. Auparavant, une entrée absolue était cherchée telle qu’écrite, si bien qu’une entrée avec une étoile ne correspondait à rien — et, étant un joker, n’était jamais signalée non plus comme ne correspondant à rien. Un rapport qui y apparaît plus tard est chargé par l’observateur ou par l’interrogation périodique comme une entrée littérale ; un joker qui ne correspond à rien n’est pas signalé, car il peut attendre un build.

Corrigé

• Un rapport JSON llvm-cov était refusé comme format non pris en charge. Le format est reconnu d’après les 4096 premiers caractères, et llvm-cov écrit son marqueur "type": "llvm.coverage.json.export" tout à la fin ; un export dont le premier enregistrement de fichier porte de nombreuses branches et des expansions de macros imbriquées n’avait rien d’autre de reconnaissable dans ce début. Un tel rapport est désormais reconnu à son ouverture, {"data":[{"files":[, qu’aucun autre format n’a.
• De même pour gcov --json-format. gcov écrit les fonctions d’un fichier avant ses lignes, et un fichier d’une douzaine de fonctions n’a pas non plus d’entrée de ligne dans le début inspecté ; la clé gcc_version propre au document l’identifie désormais.

Ajouté

• Choisir ou combiner les rapports d’un fichier. Faites un clic droit sur un fichier dans la fenêtre Coverage et choisissez Choose Coverage Source... — proposé là où plus d’un rapport chargé le mesure — ou utilisez Tools > Coverage Studio > Choose Coverage Source for This File... : chaque rapport avec ses propres chiffres, puis Combine them — agree (couvert seulement là où chaque rapport a exécuté une ligne : une base de code, deux compilateurs) et — union (couvert là où l’un d’eux l’a fait : plusieurs suites de tests d’un même build), pour le fichier, son dossier ou un motif. Les lignes sur lesquelles les rapports divergent sont en bleu sarcelle dans la marge et dans l’Annotated Source, avec ce que chaque rapport a dit ; la ligne du fichier nomme les rapports et le nombre de lignes en litige, et la barre d’état et les deux cartes disent d’où viennent les chiffres.
• Rouge, ambre et vert. Gutter: Coverage peint chaque ligne couverte en vert à côté du rouge et de l’ambre — le mode pour quiconque s’attendait à ce qu’un fichier à 100 % soit vert. Les cinq teintes de la carte de chaleur sont des réglages (heatmap.colors, heatmap.colorsDark), et la fenêtre des réglages prévisualise chaque couleur pendant qu’on la choisit.

Corrigé

• Le chiffre du fichier dans la barre d’état est celui de sa carte. Une métrique vide — le MC/DC d’un fichier sans décisions — comptait pour 100 % dans l’élément et pas du tout sur la carte qu’il ouvre.
• Un en-tête de constantes n’affiche plus 0 % ni 100 %. Les directives du préprocesseur comptent comme du non-code, comme les commentaires, lorsque excludeComments est activé.

Ajouté

• Choisir ou combiner les rapports d’un fichier. coverageFile.sources décide, fichier par fichier, lequel de plusieurs rapports chargés parle pour lui — ou les combine : agree ne compte une ligne comme couverte que là où chaque rapport l’a exécutée, et marque en bleu sarcelle les lignes sur lesquelles ils divergent ; union là où l’un d’eux l’a fait. Choose Coverage Source... sur une ligne de la vue Coverage ou pour le fichier ouvert écrit la règle pour vous. Fait partie des offres payantes ; sur Community, le rapport le plus récent décide.
• Rouge, ambre et vert, et un mode de gouttière en un clic. Le mode coverage peint les lignes couvertes en vert ; les teintes de la carte de chaleur sont des réglages, avec un aperçu en direct dans le panneau des réglages ; un bouton de la barre d’état et Alt+G font passer la gouttière par désactivé, non couvert, couverture et carte de chaleur.

Corrigé

• Le chiffre du fichier dans la barre d’état est celui de sa carte. Une métrique vide — le MC/DC d’un fichier sans décisions — comptait pour 100 % dans l’élément et pas du tout sur la carte qu’il ouvre.
• Un en-tête de constantes n’affiche plus 0 % ni 100 %. Les directives du préprocesseur comptent comme du non-code, comme les commentaires, lorsque excludeComments est activé.

Modifié

• La boîte de dialogue Licence ne demande plus que le code. Les quatre boutons de forfait ont disparu : un code d’abonnement ou d’invitation désigne un pool, et le pool connaît son forfait, si bien qu’il n’y avait rien qu’une personne puisse répondre mieux que le code lui-même — et une invitation Business collée alors que Pro était encore sélectionné était refusée pour mauvais forfait. Collez le code et appuyez sur Activate.

Modifié

• Enter Subscription Code ne demande plus que le code. La question du forfait a disparu : le code désigne un pool et le pool connaît son forfait, si bien que le serveur prend le relais et ne refuse plus un code comme étant pour le mauvais forfait. Les liens en un clic dans les e-mails sont inchangés ; les e-mails d’activation n’ont plus d’étape « choisissez votre forfait », et le même code active Coverage Studio pour Visual Studio sans que VS Code soit nécessaire.

Ajouté

• La couverture après chaque exécution de tests. Collect Coverage in Test Explorer… place un .runsettings avec le collecteur Cobertura de Microsoft à côté de la solution — repris de lui-même avec Tools → Options → Test → Auto detect runsettings files activé, ou sélectionné une fois sous Test → Configure Run Settings ; dès lors, chaque exécution du Test Explorer écrit un rapport sous le projet de test, et il est chargé à l'instant où il apparaît, fusionné avec tout ce que les réglages nomment. Rien ne s'accroche au Test Explorer, si bien que Visual Studio 2026 et Microsoft.Testing.Platform fonctionnent tels quels. Run Tests with Coverage reconnaît dotnet test, vitest, jest, pytest, go, cargo, maven, gradle, phpunit et ctest, les lance avec la couverture activée dans la fenêtre Output et charge ce qu'ils ont écrit ; un projet de test sans coverlet.collector est lancé avec le collecteur livré par le SDK de test.
• Depuis la dernière exécution. Chaque chargement est comparé au précédent : un triangle dans la marge sur chaque ligne qui a commencé ou cessé de s'exécuter, la tendance à côté du score, et Compare with Last Run pour les fichiers dont les chiffres ont bougé. history.enabled conserve les exécutions d'un redémarrage à l'autre ; gitDiff.enabled réduit l'exécution aux lignes que votre branche a modifiées.
• Les seuils et l'Error List. Check Coverage Thresholds juge l'exécution selon threshold.* ; avec compliance.diagnostics, problems.enabled, problems.perLine ou deadCode.enabled, les constats figurent dans l'Error List à côté de ceux du compilateur, chacun ouvrant son fichier.
• Rapports, exports et un badge. Show Annotated Source ouvre le fichier actif comme une page dans la zone des documents — chaque ligne dans sa couleur, les constats à côté — qui défile avec l'éditeur dans les deux sens. Open HTML Report et Generate Full HTML Report écrivent l'exécution dans htmlReport.outputDir et ouvrent le navigateur. Export Coverage Report… écrit du CSV par fichier ou par fonction, du Markdown, du LCOV, du Cobertura, du SARIF, un badge SVG ou du Fucini JSON. Generate Coverage Badge garde le badge dans le dépôt, après chaque chargement avec badge.autoUpdate.
• Risk hotspots et filtres de lignes dans la fenêtre Coverage, comme dans VS Code : les fonctions où du code complexe rencontre peu de couverture, la pire en premier ; et une liste déroulante à côté du tri pour tous les fichiers, les fichiers avec des lacunes, les fichiers non testés, ou les fichiers modifiés depuis la dernière exécution.
• Un fichier de réglages à la racine de la solution. fucini-coverage.json à côté de la solution est lu après .vscode/settings.json et écrit par la fenêtre de réglages quand c'est le fichier qui existe — pour une équipe qui préfère ne pas garder de dossier .vscode. Les deux éditions le lisent.
• .NET sans cérémonie. ignore.generated laisse les fichiers de designer, générés, obj\ et de migration hors de chaque total ; testRun.skipWhenTestsFail garde la dernière bonne couverture à l'écran quand une exécution se termine au rouge.

Pas encore dans cette édition

• Le panneau Test Coverage est une API VS Code, et l'Explorateur de solutions ne peut pas afficher de badges. Compare Two History Runs suivra quand des abonnés le demanderont.

Ajouté

• Quels fichiers afficher. Une seconde liste déroulante dans la barre d'outils de la vue Coverage, à côté du tri : tous les fichiers, les fichiers avec des lacunes, les fichiers non testés, ou les fichiers dont les chiffres ont bougé depuis l'exécution précédente. Les dossiers suivent leurs fichiers et gardent leurs propres chiffres. Dans chaque forfait.
• Risk hotspots. Sous l'arbre : les fonctions où du code complexe rencontre peu de couverture, la pire en premier, chacune ouvrant son fichier à la fonction. Une fonction se qualifie par son score CRAP — hotspots.crapThreshold, 30 par défaut, le chiffre proposé par les auteurs de la métrique — ou par sa seule complexité cyclomatique, hotspots.complexityThreshold, désactivé par défaut. Community voit le nombre et le pire score ; la liste classée est Pro.
• dotnet test sans paquet. Run Tests with Coverage lit d'abord les fichiers de projet : là où aucun ne référence Coverlet, l'exécution utilise le collecteur de Microsoft — --collect:"Code Coverage;Format=cobertura" — livré avec Microsoft.NET.Test.Sdk, et son rapport est chargé comme celui de Coverlet.
• Les fichiers .NET générés sont laissés de côté. ignore.generated, activé par défaut, retire *.Designer.cs, *.g.cs, *.generated.cs, *.razor.g.cs, AssemblyInfo, les usings globaux, tout ce qui est sous Migrations/ et sous obj/ de chaque total, page et export. Un fichier de designer que personne ne teste ne coûte plus son seuil à une solution.
• Une exécution échouée garde la dernière bonne couverture. Avec testRun.skipWhenTestsFail, une exécution qui se termine sur un test en échec laisse la couverture à l'écran telle qu'elle était, et le dit dans le volet Output. Désactivé par défaut.

Modifié

• Une exécution du Test Explorer est trouvée d'elle-même. Sans rien configurer, les noms connus comprennent désormais le dossier TestResults/<run>/ de chaque projet de test, et pas seulement celui du dossier de l'espace de travail, ainsi que le <user>_<machine>_<date>.cobertura.xml du collecteur de Microsoft à côté de celui de Coverlet. Une solution .NET dont les tests ont été lancés dans Visual Studio montre sa couverture dès la première ouverture ; chaque dossier d'exécution est chargé, et la fusion garde pour chaque fichier le dernier mot de l'exécution la plus récente.

Ajouté

• Une seconde extension, pour Visual Studio 2022 et 2026 — Community, Professional et Enterprise. Le même lecteur que l'édition VS Code, donc le même rapport donne les mêmes chiffres, au chiffre près, dans les deux éditeurs ; et les mêmes réglages fuciniCoverage.*, lus dans .vscode/settings.json comme dans les réglages utilisateur de VS Code quand il est sur la machine. Elle n'utilise pas la couverture de code propre à Visual Studio : dans Visual Studio 2022, c'est une fonction Enterprise, et sur Community et Professional c'est la seule couverture que l'IDE affichera.
• Dans l'éditeur : une barre en marge par ligne — rouge jamais exécutée, ambre en partie, une carte thermique par nombre de passages — des compteurs en ligne, une ligne au-dessus de chaque fonction avec sa couverture, sa complexité, son score CRAP et MC/DC, des rayures sur la barre de défilement, un survol qui dit quelle branche n'a pas été prise, et un point sur une ligne modifiée depuis le rapport.
• La fenêtre Coverage (View → Other Windows → Coverage) : chaque fichier avec ses métriques et un score sur l'ensemble, triable, avec les fichiers non mesurés en dessous ; les éléments Coverage et File de la barre d'état, chacun ouvrant la carte complète.
• Commandes sous Tools → Coverage Studio, avec des accords en deux frappes après Ctrl+Shift+U : N/P pour la ligne non couverte suivante et précédente, B pour la prochaine décision partiellement testée, R pour recharger. Le mode veille recharge quand le fichier écrit par votre build change.
• Getting Started, les six étapes avec un bouton pour chacune, en 18 langues ; s'ouvre de lui-même la première fois.
• Réglages depuis l'engrenage de la barre d'outils de la fenêtre Coverage, qui écrit les réglages utilisateur de cette édition ou le .vscode/settings.json du dossier et conserve les commentaires d'un fichier qu'il modifie.
• Licence : incluse dans chaque forfait payant. Une machine où Coverage Studio pour VS Code est activé n'a besoin de rien de plus — la clé est trouvée d'elle-même ; partout ailleurs, Tools → Coverage Studio → Licence… accepte le code d'abonnement de votre e-mail d'activation. Sans abonnement, aucune couverture n'est lue : il n'y a pas de niveau gratuit dans Visual Studio.

Pas encore dans cette édition

• Run Tests with Coverage et le panneau Test Coverage sont des API VS Code ; l'Explorateur de solutions ne peut pas afficher de badges. La vue Annotated Source, le rapport HTML et les exports, Check Thresholds, les entrées de l'Error List, l'historique et la tendance, et la couverture des diffs suivent dans l'ordre où les abonnés les demandent.

Ajouté

• Une visite guidée. Get started with Coverage Studio — sous Help → Welcome → Walkthroughs, et ouverte d'elle-même après l'installation — mène un nouvel utilisateur en six étapes d'un rapport de couverture aux lignes que personne ne teste, chacune avec un bouton pour la commande dont elle parle. Dans les dix-huit langues.
• L'identifiant d'installation est laissé là où Coverage Studio pour Visual Studio le lit. L'édition Visual Studio vérifie la clé de license.key contre la même empreinte et ne peut pas lire le stockage d'état de cette extension ; à chaque activation, l'identifiant est désormais aussi écrit à côté du stockage global de l'extension, de sorte qu'une machine activée dans VS Code n'a pas besoin d'une seconde activation dans Visual Studio. Un UUID aléatoire, lié à rien, jamais envoyé nulle part.

Modifié

• Un remboursement met fin à l'abonnement. Un remboursement ou une rétrofacturation approuvés annulent désormais l'abonnement immédiatement et son code d'activation n'émet plus de clés ; un remboursement par client. Les clés déjà présentes sur une machine courent jusqu'à leur propre expiration, comme avant. La politique de remboursement dit exactement ce qui se passe.

Corrigé

• Les noms de fichiers de la vue Coverage sont lisibles à toute largeur. Le nom était la seule partie d’une ligne à rétrécir — jusqu’à sept caractères dans une barre latérale ordinaire. Il est désormais dessiné en entier, et les colonnes de métriques, le score et la barre glissent dessous par la gauche, en s’estompant à la coupe pour qu’un demi-nombre ne se lise jamais comme un nombre entier. Chaque valeur reste dans l’info-bulle de la ligne.
• La marque « le fichier a changé » suit le fichier. Après un chargement, elle suivait la première modification et la première restauration, puis plus rien ne la faisait bouger jusqu’au chargement suivant. Chaque enregistrement et chaque changement sur le disque est maintenant pris en compte.
• La barre d’outils de la vue Coverage ne coupe plus les libellés de ses boutons. Dans une barre latérale étroite, elle passe désormais à la ligne entre ses contrôles, et la liste de tri prend une ligne à elle.
• Le badge de couverture est gratuit aussi dans le sélecteur d’export. Generate Coverage Badge a toujours écrit le badge SVG à tous les niveaux, alors que Export Coverage Report… refusait le même fichier en Community. Les deux l’écrivent désormais.
• Show Worst-Covered Folders est sous licence comme les deux autres listes. Rien ne change en Community, où les trois sont gratuites et non comptées, ni pour aucune clé déjà émise.

Ajouté

• Une version minimale prise en charge. L’extension lit désormais, environ une fois par semaine, une petite politique signée sur notre serveur de licences. Lorsqu’une version est plus ancienne que la plus ancienne encore prise en charge, l’essai et le niveau gratuit s’arrêtent et demandent une mise à jour ; une licence payante est informée de la date et continue d’abord de fonctionner pendant un délai de grâce. Cette lecture n’envoie rien sur vous ni sur votre installation, et une installation qui ne peut pas joindre le serveur n’est jamais arrêtée pour cette raison. Aucun minimum n’est fixé aujourd’hui.

Modifié

• La licence est propriétaire à partir de cette version. L’extension était publiée sous les termes MIT, ce qui n’a jamais correspondu à un produit vendu par abonnement. Vous pouvez installer et utiliser la version publiée dans les limites de votre offre, y compris à des fins commerciales ; vous ne pouvez pas la copier, la modifier, la redistribuer ni en faire l’ingénierie inverse. Ce qu’elle produit à partir de vos données — rapports, exports, badges — vous appartient, et l’ancienne condition d’attribution disparaît. Une copie d’une version antérieure reste sous les termes qui l’accompagnaient.
• Le bouton des actions de chemin (⋯) n’occupe aucune place tant que vous ne pointez pas une ligne. Les 25 pixels qu’il gardait réservés sur chaque ligne reviennent au nom du fichier ; il apparaît juste après le nom au survol, et rien ne bouge dans la ligne.

Corrigé

• Les tracefiles LCOV 2 listent chaque fonction une seule fois. FN:<ligne>,<ligne de fin>,<nom> est lu tel que lcov 2.0 l’écrit — auparavant chaque fonction apparaissait deux fois, une fois comme jamais appelée et une fois à la ligne 0 — et les paires FNL:/FNA: de lcov 2.2 sont lues avec lui.
• Un template C++ n’est plus peint comme jamais exécuté parce qu’une instanciation ne l’était pas, et une fonction pleine de macros redevient une seule fonction au lieu d’une par macro.
• Les textes de consentement disent ce que l’installation envoie réellement : plus de page mensuelle de votre code, et votre résumé d’utilisation porte le code de demande sur lequel votre clé a été émise.

Ajouté

• La couverture des conditions est une métrique à part entière. a && b est une décision et deux conditions, et une suite peut prendre les deux branches sans jamais voir b faux. Elle a désormais sa ligne, sa colonne, ses exports, son badge, son poids dans le score (3, entre les branches et le MC/DC) et son seuil — lue depuis BullseyeCoverage, un export cond TRACE32 et -fcondition-coverage de GCC 14.
• Les mutants, là où ils sont. Les rapports PIT et Stryker sont lus mutant par mutant : ceux qui survivent sont marqués sur leur propre ligne dans l’éditeur, avec la modification et les tests qui l’ont exécutée au survol, et listés dans le rapport HTML et la source annotée.
• Quels tests ont exécuté cette ligne. coverage.py avec --show-contexts et OpenCover avec -coverbytest disent tous deux quels tests ont atteint une ligne ; l’infobulle du compteur les nomme.
• La partie d’une ligne exécutée qui n’a jamais tourné est teintée dans l’éditeur, et les fonctions C et C++ reçoivent une complexité et un score CRAP comptés à partir des données de branche que llvm-cov porte déjà.
• Les projets JaCoCo, Cobertura et Coverlet se chargent dès la première ouverture, sans rien configurer — y compris là où Maven, Gradle et dotnet test écrivent par défaut.
• Chaque métrique à côté de chaque fichier, quelle que soit la largeur, classée par le poids qu’elle a dans votre score, ce qui ne tient pas défilant au lieu de disparaître — et un compteur sur l’icône Coverage quand un tracefile se recharge pendant que vous regardez ailleurs.
• Un canal de préversion auquel vous pouvez vous porter volontaire, et un bouton dans la barre de titre de l’éditeur qui coupe la coloration de couverture et ramène exactement ce qu’elle avait.

Modifié

• Bullseye et TRACE32 : la couverture des branches n’inclut plus les conditions. Les décisions sont la couverture des branches et les conditions la couverture des conditions ; le chiffre des branches d’un tel projet change donc, et le score composite avec lui. Mettez whmWeights.conditions à 0 pour retrouver le score d’avant.
• Le niveau Community gratuit a un quota hebdomadaire : cinq par semaine pour chacune des actions comptées, là où il y en avait vingt par jour, et à la limite un abonnement ou un pass de 7 jours est proposé. Une installation déjà en service garde ses anciens quotas 30 jours et en est informée une fois, avec la date.
• L’essai et le niveau gratuit tiennent un registre d’usage avec le serveur de licences : une empreinte de l’identifiant machine de VS Code, l’édition, le jour où l’évaluation a commencé et les compteurs des actions mesurées — rien d’autre, jamais sur une licence payante, et jamais attendu. L’échange contre la télémétrie est désormais de 30 jours, une seule fois.
• La page mensuelle de code source a disparu — elle n’est plus collectée, conservée ni envoyée, pour personne, et celle qu’une version antérieure aurait gardée est supprimée au premier démarrage de celle-ci.

Corrigé

• La carte de chaleur se lit dans le bon sens sur un thème sombre. Son dégradé allait du jaune pâle au brun foncé, si bien que la boucle la plus chaude avait la barre la plus terne. Un thème sombre dispose désormais de son propre dégradé, de l’olive atténué à l’orange vif.
• Le survol MC/DC affiche de nouveau son détail, et une décision llvm-cov compte correctement ses conditions. La version actuelle de VS Code repliait le survol sur une seule ligne ; et (a && b) || c était listée avec une seule condition à 100 % sous un titre qui indiquait à juste titre 2 paires sur 3.
• Les fonctions C++ portent le nom que vous leur avez donné : clamp_to<int> et gearbox::next_gear au lieu du nom de l’éditeur de liens ??$clamp_to@H@@YAHHHH@Z, pour llvm-cov, lcov et gcov.
• Les décomptes de lignes d’Istanbul correspondent à ceux de nyc, le XML de dotnet-coverage est lu, les lignes SimpleCov :nocov: sont exclues au lieu d’être traitées comme défectueuses, et un rapport qui ne contient qu’un résumé conserve ses chiffres quel que soit l’ordre de lecture des rapports.
• Espaces de travail multi-racines : le rapport HTML ne nomme plus un dossier deux fois, la vue Coverage place en tête d’un dossier d’espace de travail son nom, et une règle pathRemap peut employer ${workspaceFolder} aussi bien que ${workspaceRoot}.

Ajouté

• Tout ce que contient un rapport est affiché. Les appels de fonction, le code objet et un score de mutation obtiennent une colonne dans la vue Coverage, le rapport HTML et les exports CSV et Markdown, une ligne dans les cartes de la barre d’état et un badge dans le source annoté — et une métrique qu’un rapport ne contient pas est omise plutôt qu’affichée à zéro.
• Complexité et CRAP. Lorsqu’un rapport contient la complexité cyclomatique (OpenCover, JaCoCo, Clover, Cobertura), chaque fonction reçoit un score CRAP sur son CodeLens, un fichier reçoit un Max CRAP qui renvoie à la méthode, et le rapport HTML liste les Riskiest Methods.
• Davantage de chaque format : les bras de branche nommés, les lignes exclues, les plages de colonnes à l’intérieur d’une ligne, l’outil, la version et la date du rapport, ainsi que les avertissements qu’un outil y a inscrits.
• Des poids facultatifs pour le code objet et le score de mutation dans le score composite, tous deux à 0 tant que vous ne les définissez pas.

Modifié

• Les seuils par défaut ne sont plus de 100 %. Un seuil que vous n’avez pas défini vaut désormais 80 pour les lignes, 80 pour les fonctions, 75 pour les régions, 70 pour les branches et 75 pour le score composite, sans garde-fou sur le MC/DC, les instanciations, les appels de fonction ni le code objet — ce que l’on peut exiger d’un projet ordinaire. fuciniCoverage.threshold.profile: "safety" replace chaque garde-fou à 100, exactement comme avant, et un seuil que vous avez défini l’emporte sur l’un et l’autre profil. Si vous comptiez sur les anciennes valeurs par défaut, vous êtes jugé avec plus d’indulgence tant que vous n’avez pas sélectionné safety ; une installation qui fonctionnait déjà auparavant en est informée une seule fois, avec un bouton qui définit le profil.
• Une métrique sans garde-fou affiche un tiret neutre dans les cartes au lieu d’une coche ou d’une croix, et le panneau des paramètres donne un aperçu du verdict avec les garde-fous réellement en vigueur.

Corrigé

• La couverture dans un tampon aux modifications non enregistrées est alignée. Une exécution chargée alors qu’un fichier avait des modifications non enregistrées décalait chaque marque, survol et CodeLens d’autant de lignes que ces modifications les avaient poussés. Les modifications sont désormais retrouvées à partir du fichier sur le disque, et une ligne entière collée au-dessus d’une ligne ne compte plus cette ligne comme modifiée.
• Les fusions et les enregistrements LCOV répétés s’additionnent. Un fichier de trace plus récent ne conserve plus les résumés de branches et MC/DC de l’exécution précédente, et un fichier listé deux fois dans un même fichier de trace est combiné comme genhtml le fait.
• La clé de licence reste sur sa machine. Settings Sync ne la transporte plus vers les autres installations, où elle bloquait la couverture ; une clé Business, Enterprise ou Pro Plus expirée se renouvelle d’elle-même jusqu’à 45 jours après l’expiration.
• Les fichiers de trace distants sont récupérés avec plus de soin. Les remote.headers restent sur leur origine à travers les redirections, une récupération abandonne après 30 secondes, une page de connexion est refusée plutôt que mise en cache, et une fenêtre ouverte hors ligne charge la dernière copie téléchargée. La mise à jour automatique n’installe que sa propre édition.
• Analyseurs : les comptes de lignes llvm-cov correspondent à llvm-cov show, les décisions OpenCover de méthodes différentes ne s’écrasent plus, xccov, TRACE32 et EMMA conservent leurs chiffres de lignes, les classes Cobertura partageant un fichier forment un seul fichier, les rapports agrégés JaCoCo sont lus, et le mappage de chemins résout .. et compare des segments entiers.
• Dans l’éditeur : l’historique est conservé par espace de travail, les marques restent sur de vrais fichiers plutôt que sur le volet HEAD d’un éditeur de diff, les lignes au-delà de la fin d’un fichier ne sont pas peintes, les badges de l’Explorateur sous Windows fonctionnent pour les chemins C:\…, et les grandes exécutions se consultent plus vite.

Ajouté

• Envoyer un rapport de diagnostic. Les notifications d’un chargement, d’une récupération distante, d’une fusion, d’une comparaison d’historique ou d’un chat en échec le proposent. Il affiche exactement le JSON qui serait envoyé, avec en option un extrait de fichier de 4 Ko, un commentaire et une adresse de réponse, et n’envoie rien tant que vous ne cliquez pas sur Envoyer.
• Rapports d’erreur. Une erreur FUCINI_* est signalée sans contenu de fichier, chemins ni noms lorsque le niveau de télémétrie de VS Code est all ou error. Trois lignes du journal ont leur propre code : FUCINI_REMOTE_002, FUCINI_REMOTE_003 et FUCINI_GITDIFF_002, chacun décrit dans le guide utilisateur.

Modifié

• Chaque pourcentage de couverture a deux décimales, tronquées plutôt qu’arrondies : 87.43%, et 100.00% seulement lorsque la couverture est exactement de 100.
• Les seuils tranchent sur la valeur exacte. Jusqu’ici chaque pourcentage était d’abord arrondi à l’entier, si bien que 89,6 % passait un seuil de 90 %. Un projet qui ne passait que grâce à l’arrondi affiche désormais NON-COMPLIANT jusqu’à ce que sa couverture atteigne réellement le seuil.
• La télémétrie est quotidienne. Chaque installation envoie un petit message de licence quotidien au niveau de télémétrie all de VS Code ; avec telemetry.enabled activé, le résumé d’utilisation part chaque jour au lieu de chaque mois. Les installations ayant débloqué des fonctions contre la télémétrie sont consultées avant que leurs conditions changent.

Ajouté

• La vue Coverage signale une mise à jour disponible, et continue de la signaler. Une barre au-dessus de la bannière de licence indique la nouvelle version à côté de la vôtre, avec les trois mêmes boutons que la notification de mise à jour : « Télécharger & installer », « Voir le journal des modifications » et « Ignorer cette version ». L’icône de la vue dans la barre d’activité porte aussi un badge, visible même quand la vue est fermée. La notification n’apparaissait qu’une fois, lors de la vérification automatique, et un clic ailleurs la faisait disparaître jusqu’à la vérification suivante, un jour plus tard ; la barre reste jusqu’à ce que la mise à jour soit installée ou ignorée, ou que fuciniCoverage.update.checkForUpdates soit désactivé, et survit au rechargement de la fenêtre.

Modifié

• Les petits pings partent au plus une fois par jour, regroupés. Une mise à jour, un changement de licence, un nouveau format de couverture et un fichier illisible faisaient chacun l’objet d’un ping, envoyé dès qu’ils étaient remarqués — et, sur certaines installations, remarqués à nouveau à chaque session : un siège révoqué signalait sa révocation à chaque démarrage, et passer d’un espace de travail à un autre utilisant des formats différents signalait à chaque fois un « nouvel » ensemble. Ils sont désormais regroupés et envoyés en un seul ping, au plus une fois par jour. Une journée sans rien à signaler n’envoie rien.
• Seul ce qui a réellement changé est signalé. Une licence qui change puis revient à son état initial dans la journée ne signale rien, et les formats sont tous ceux que l’installation a chargés, et non ceux du dernier espace de travail. Le ping d’installation et l’avis de désinstallation partent toujours immédiatement, et rien de nouveau n’est collecté.
• L’interrupteur de télémétrie de VS Code s’applique désormais aussi aux petits pings. Si telemetry.telemetryLevel vaut off, rien n’est collecté pour le ping quotidien et rien n’est envoyé ; jusqu’ici, seuls le récapitulatif mensuel et l’avis de suppression le respectaient. Le ping d’installation unique est inchangé.
• Un mois qui se termine pendant que l’éditeur est inactif est tout de même signalé. Le récapitulatif mensuel n’était vérifié qu’après le chargement d’une couverture, si bien qu’une installation qui n’était plus utilisée n’envoyait jamais son dernier mois. Il est désormais aussi vérifié toutes les heures tant que VS Code est ouvert — toujours uniquement avec la télémétrie activée, et toujours au plus une fois tous les 30 jours.

Corrigé

• Un ping refusé par le serveur ne compte plus comme envoyé. Toute réponse du serveur, erreur comprise, valait livraison : un ping quotidien refusé perdait ce qu’il avait collecté et un ping d’installation refusé n’était pas retenté. Seule une réponse réussie compte désormais ; un ping quotidien ou un récapitulatif mensuel refusé est conservé et retenté un jour plus tard.

Modifié

• Chaque évaluation reçoit 14 nouveaux jours, une fois. Au premier démarrage de cette version, l’essai se rouvre sur chaque installation Pro sans licence payante — qu’il ait pris fin depuis longtemps ou qu’il lui reste encore quelques jours — et dure 14 jours à compter de ce jour-là. Un bref avis l’indique au moment où cela se produit. Une licence payante n’est pas touchée, et l’édition Community, qui n’a pas d’essai, reste inchangée.
• Une licence payante affiche « Activé », en vert. La bannière de licence montrait jusqu’ici à un abonné « Activé — 30 jours restants ». Une clé d’abonnement court jusqu’à la fin de la période payée et se renouvelle avec elle, si bien que ce compte à rebours n’aurait jamais cessé de ressembler à un essai sur le point d’expirer. Le titre dit désormais simplement Activé, la date figure dans les détails sous « Valable jusqu’au », et le compte à rebours ne revient que pendant la dernière semaine avant l’expiration d’une clé, à côté de la note de renouvellement imminent qui s’y trouvait déjà.

Ajouté

• « Enter Subscription Code » — et rien d’autre ne vous est demandé. Choisissez votre offre, collez le code reçu dans l’e-mail d’achat, confirmez : votre clé de licence est délivrée et appliquée pour vous. Jusqu’ici, la seule voie depuis l’éditeur passait par le questionnaire d’évaluation — nom, e-mail, type de compte, société, une enquête —, soit le mauvais formulaire à présenter à quelqu’un qui a déjà payé. L’autre voie était le lien vscode:// de l’e-mail, et se méfier d’un tel clic est raisonnable plutôt que timide : un lien de ce genre peut être déclenché par n’importe quelle page que vous visitez, et c’est précisément pourquoi l’activation vous demande de confirmer. La commande est dans la palette de commandes, et c’est un bouton sur la bannière de licence du panneau de couverture et dans la boîte de dialogue d’activation — dans tous les états, car une licence passe d’une machine à l’autre et acheter en cours d’essai est le cas ordinaire, non l’exception.
• Un moyen de voir les offres depuis l’essai lui-même. La page des tarifs était accessible depuis les écrans de l’édition gratuite, mais pas depuis la boîte de dialogue d’activation ni depuis la bannière de licence — le seul endroit que regarde vraiment celui qui lit « 3 jours restants ». On lui proposait un questionnaire et une indication sur settings.json, et aucun prix.

Modifié

• La boîte de dialogue d’activation et la bannière de licence ne s’ouvrent plus sur FCK1. Toutes deux commençaient par votre code de demande et par « collez la clé dans settings.json », qui est la voie prévue lorsque notre serveur de licences est totalement injoignable. Montré en premier, cela se lisait comme la consigne — si bien qu’un client muni d’un code d’abonnement FCB1… était envoyé vers « Enter Activation Key », le seul champ certain de le refuser. Les deux restent présents, sous les voies qui conviennent à quelqu’un qui a acheté, et décrits pour ce qu’ils sont réellement.

Corrigé

• « Request Activation Key » est désormais une vraie commande. Votre e-mail d’achat — et la page d’activation, dans toutes les langues — vous dit que si le lien en un clic ne survit pas à votre messagerie, vous pouvez lancer Fucini Coverage: Request Activation Key depuis la palette de commandes, choisir votre offre et coller votre code. Ce nom appartenait à la barre de titre du panneau et au lien lui-même, jamais à une commande : la palette n’avait donc rien à proposer dessous — et la correspondance la plus proche par le nom, Enter Activation Key, attend la clé FCK1… délivrée par notre serveur, et non le code FCB1… que porte votre e-mail. Suivre les instructions vous menait au seul champ certain de refuser ce que vous aviez entre les mains. C’est maintenant une commande réelle.
• La boîte de dialogue d’activation propose Demander une licence… alors qu’une période d’essai ou une clé est encore valide. Ce bouton était retenu jusqu’à l’expiration de l’une des deux, au motif qu’une installation qui fonctionne n’a aucune raison de contacter le serveur de licences. Or acheter en cours d’essai est le cas ordinaire et non l’exception, et l’acheteur dans cette situation n’avait, depuis la boîte de dialogue, aucun chemin vers le champ où va son code : les deux boutons restants réclamaient une clé que seule l’utilisation du code pouvait produire.

Ajouté

• Une palette pour daltoniens. Réglez colorScale.preset sur colorblind et la couverture est dessinée en vermillon, orange et bleu (la palette Okabe–Ito) au lieu de rouge, ambre et vert — dégradé, barres de marge, surlignage des lignes, badges de l'Explorateur et marques depuis la dernière exécution. Une couleur que vous avez définie vous-même reste prioritaire.

Ajouté

• Filtrer la couverture par test dans la vue Test Coverage de VS Code. Quand un fichier de trace nomme ses tests — les sections TN: de lcov —, chaque test devient un élément sous Fucini Coverage dans le Test Explorer, chaque fichier de la vue Test Coverage liste les tests qui y ont exécuté quelque chose, et en choisir un affiche les lignes que ce test a atteintes.
• ${command:…} dans les réglages de chemin. ${command:cmake.buildDirectory}/coverage.info suit le kit CMake sélectionné. La commande s’exécute avant chaque découverte, cinq secondes au plus et seulement dans un espace de travail approuvé ; une commande qui échoue laisse la variable telle qu’écrite, et la sortie dit pourquoi.
• Un démarrage rapide en 30 secondes et une comparaison avec les alternatives ouvrent désormais la page Marketplace et la page d’accueil.

Corrigé

• Un fichier de trace qui enregistrait un fichier une fois par test le comptait une fois par test. Les enregistrements sont désormais additionnés par fichier de trace, comme genhtml les lit : le fichier compte une seule fois dans les totaux, et avec plusieurs fichiers de trace chargés, aucun test ne perd ses lignes.

Corrigé

• L’identifiant d’installation est désormais enregistré avant que quoi que ce soit ne l’utilise. La build 2 de 0.2026.72 a cessé de recalculer l’identifiant à chaque appel, mais le démarrage n’attendait toujours pas qu’il soit écrit : une fenêtre fermée juste après son ouverture pouvait donc encore le perdre — et avec lui l’empreinte de la machine à laquelle une clé d’activation est liée. Le démarrage attend maintenant.
• Passer de Pro à Community ne rend plus votre clé d’activation invalide. Chaque édition a son propre stockage d’extension : Community démarrait donc avec un nouvel identifiant d’installation et une nouvelle empreinte, alors que la clé de vos paramètres — y compris celle que le changement venait de demander pour le déverrouillage gratuit — était liée à l’ancienne. Le changement transmet désormais l’identifiant.

Sécurité

• Les mises à jour de fucini.software sont signées et vérifiées avant d’être installées. Chaque .vsix du flux de mises à jour porte une empreinte SHA-256 et une signature Ed25519 produite par une clé qui ne se trouve jamais sur le serveur web. Le programme de mise à jour intégré et le passage à Community vérifient les deux sur le fichier téléchargé et refusent tout le reste — la page d’erreur d’un proxy, un téléchargement tronqué, une ancienne build en cache ou un fichier qui ne vient pas de nous. HTTPS seul ne suffit pas : un proxy d’entreprise qui inspecte TLS re-signe chaque connexion qu’il voit passer.
• Chaque version a son propre nom de fichier. Le flux de mises à jour pointe désormais vers un .vsix versionné plutôt que vers un fichier écrasé à chaque version, si bien qu’un cache qui ignore Cache-Control ne peut pas servir la build du mois dernier pour celle de ce mois-ci. Les liens de la page de téléchargement ne changent pas.

Ajouté

• Aller aux décisions testées dans un seul sens. Next Partly-Tested Decision et son jumeau précédent parcourent les branchements dont certaines branches ont été exécutées et d’autres jamais. C’est la lacune que la navigation entre lignes non couvertes ne peut pas montrer : une ligne dont l’instruction s’est exécutée est couverte, et le reste quel que soit le nombre de branches jamais prises — if (a && b) atteint une fois avec a faux est couvert à 100% en lignes et testé à moitié. Un arrêt par décision plutôt que par branche, car les branches d’un if/else peuvent être séparées par des pages, et sauter à la cinquième branche d’un switch en dit moins que sauter au switch lui-même. Les décisions qu’aucune branche n’a jamais atteintes restent aux commandes de lignes non couvertes, qui s’y arrêtent déjà — et un fichier dont le rapport ne contient aucun branchement le dit, au lieu d’affirmer que chaque décision a été testée dans les deux sens.
• Reload Coverage relit ce qui est déjà chargé. Surveillance désactivée, le seul retour à des chiffres frais après avoir relancé les tests passait par Load Coverage, qui relance la découverte et peut revenir avec un ensemble différent de celui affiché. Cette commande relit exactement ce qui est chargé maintenant, y compris les fichiers de trace choisis à la main que la découverte ne retrouverait jamais.
• Copy Coverage Summary met l’exécution dans un tableau Markdown. Le fichier le moins couvert en premier, avec une ligne de totaux, prêt à coller dans une pull request. Les colonnes de branches et de MC/DC n’apparaissent que si quelque chose dans l’exécution les a mesurées : une colonne de tirets se lit comme une couverture nulle plutôt que comme non mesurée, ce qui est l’inverse de la vérité.

Corrigé

• L'identifiant d'installation pouvait changer d'une session à l'autre — et c'est de lui qu'est dérivée l'empreinte de licence. Il était recalculé à chaque appel et enregistré sans que rien n'attende l'écriture : un deuxième appel, ou une fenêtre de l'éditeur fermée peu après le démarrage, pouvait donc en produire un nouveau. Un identifiant qui change, c'est une clé d'activation qui ne correspond plus ; cela gonflait aussi tous les chiffres comptés par installation. Il est désormais fixé une fois par session et enregistré avant toute utilisation. Build 2.

Ajouté

• Attribution d’origine à la ligne. Avec plusieurs fichiers de trace chargés, l’info-bulle du nombre d’exécutions se termine désormais par Couvert par : et les rapports qui ont enregistré une exécution sur cette ligne — et un clic sur une ligne de fichier de trace dans la vue Coverage éclaire maintenant les lignes qu’il a apportées, dans chaque éditeur ouvert, comme il éclairait déjà les fichiers qu’il a mesurés. C’est la seule question à laquelle une exécution fusionnée peut répondre et un rapport isolé non : deux fichiers de trace qui mesurent le même fichier ne s’accordent pas sur ses lignes, et jusqu’ici la fusion aplanissait ce désaccord sans jamais le montrer. La fusion reste par fichier — le rapport le plus récent l’emporte entièrement sur un fichier partagé — donc les origines par ligne sont indexées avant elle. Seules les lignes couvertes comptent : un rapport qui a noté une ligne à 0 ne l’a pas couverte.
• L’enregistrement TN: de lcov est enfin lu. Un fichier de trace qui nomme sa suite — TN:integration — apparaît comme coverage.info (integration) partout où une origine est nommée, et ce nom survit à un export vers lcov au lieu d’être écrit vide. La plupart des outils écrivent TN: vide et ne changent pas ; ceux qui le remplissent sont précisément ceux dont les fichiers sont fusionnés, et le nom est alors la seule chose qui dise lequel est lequel.
• fuciniCoverage.lineHighlight teinte les lignes elles-mêmes. off | uncovered | heatmap, désactivé par défaut : une teinte translucide derrière chaque ligne non couverte ou partiellement couverte, et en heatmap derrière chaque ligne exécutée, d’autant plus chaude qu’elle a été exécutée souvent. Un réglage à part plutôt qu’une quatrième valeur de editorGutter.mode, car on les veut par paires différentes : les manques teintés avec la gouttière nette, ou des barres sans couleur derrière le code. Translucide parce qu’elle se trouve sous le texte, et elle teinte les manques plutôt que les lignes couvertes, pour la même raison que la gouttière.
• fuciniCoverage.overviewRuler décide seul de la bande dans la barre de défilement. follow (par défaut) fait ce qu’il a toujours fait : une bande partout où la gouttière trace une barre non couverte ou partielle, et jamais pour la carte de chaleur. uncovered la trace même avec editorGutter.mode désactivé — une carte des manques du fichier le long de la barre de défilement, et rien à côté du code. off conserve les barres et supprime la bande. La règle était auparavant liée à la gouttière : ces deux combinaisons n’existaient pas.

Corrigé

• Un fichier de trace illisible dit maintenant comme quoi il a été lu. « …n’est pas bien formé » laissait le lecteur deviner si le fichier avait seulement été reconnu comme le format qu’il croit — et un document Cobertura refusé par l’analyseur VectorCAST est un autre problème qu’un document Cobertura réellement tronqué. La notification se termine désormais par Il a été lu comme du cobertura. lorsqu’un analyseur a revendiqué le fichier. Si aucun ne l’a fait, rien n’est ajouté : « n’est pas dans un format que cette extension lit » le dit déjà entièrement.

Corrigé

• L’avis de données obsolètes dans l’infobulle de la barre d’état affiche de nouveau son icône d’horloge, au lieu du texte $(history). L’avis qui indique que les chiffres en dessous décrivent une version plus ancienne des fichiers porte la même marque $(history) que la barre d’état elle-même. Dans la barre d’état, cette marque est dessinée comme une icône d’horloge, parce que StatusBarItem.text substitue les icônes de lui-même ; l’infobulle, elle, est un MarkdownString, qui doit y consentir par supportThemeIcons et ne l’a jamais fait — si bien que la seule ligne expliquant pourquoi la couverture n’est pas fiable commençait par un morceau de syntaxe brute. L’infobulle y consent désormais.

Ajouté

• La gouttière propre à l’éditeur peut désormais afficher les lignes non couvertes, ou une carte de chaleur des passages. Par défaut, elle n’affiche toujours que des constats — barres MC/DC, triangles « depuis la dernière exécution », points des lignes modifiées — et la vue colorée d’un fichier entier reste l’Annotated Source. fuciniCoverage.editorGutter.mode permet d’en demander plus : uncovered place une barre sur chaque ligne qui n’a jamais été exécutée et une barre ambre sur chaque ligne dont l’une des branches n’a jamais été prise, et rien sur les lignes couvertes, si bien qu’un mur de vert ne cache pas les trois lignes rouges ; heatmap ajoute une teinte chaude sur chaque ligne exécutée, d’autant plus vive qu’elle a tourné souvent. Choose Editor Gutter Mode... passe de l’un à l’autre des trois depuis la palette ou le menu de la barre d’état. Le README revendiquait sans nuance des « gouttières natives » ; il dit désormais ce qui s’y trouve réellement.
• Compteurs de passages en ligne. fuciniCoverage.hitCounts.inline écrit ×12 après chaque ligne où commence une instruction, ×0 compris — le nombre qui a toujours été au survol, sans survoler. Toggle Inline Hit Counts l’active ou le désactive ; le menu de la barre d’état le propose comme Afficher ou Masquer, selon le cas.
• ${env:NAME}, ${config:section.key}, ${userHome} et ${workspaceFolderBasename} dans chaque réglage de chemin, à côté du ${workspaceFolder} déjà présent. Une variable que l’extension ne connaît pas est laissée telle quelle, si bien qu’une faute de frappe apparaît dans le journal de détection comme le chemin recherché, au lieu de disparaître.
• Une entrée de coverageFile.paths peut être une URL http(s)://. L’artefact est téléchargé dans le stockage de l’extension à chaque chargement et chargé depuis là ; la vue Coverage nomme l’URL, pas le chemin du cache. Chaque récupération est conditionnelle (ETag / Last-Modified), si bien qu’une nouvelle récupération d’un artefact inchangé ne télécharge rien, et quand une récupération échoue, la dernière copie téléchargée est chargée à la place et la raison figure dans la sortie. fuciniCoverage.remote.headers ajoute des en-têtes Name: value avec les variables développées — Authorization: Bearer ${env:CI_TOKEN} garde le jeton hors de settings.json — et fuciniCoverage.remote.refreshMinutes relance la récupération à intervalle régulier. Ajoutez #lcov.info (ou un autre nom de fichier) en fragment d’URL quand l’URL elle-même ne se termine pas par un nom de fichier, pour que le format soit connu.
• Le chargement et Generate Full HTML Report affichent leur progression, et peuvent être annulés. Un chargement de dix fichiers de trace ou plus, ou de 8 Mo ou plus, s’exécute sous une notification de progression munie d’un bouton Annuler, qui nomme le fichier en cours de lecture et la phase (lecture, puis vérification des sources) ; un chargement plus petit ne fait que faire tourner la barre d’état, comme avant. Annuler laisse l’exécution précédente chargée et le dit. Le rapport HTML fait de même pour chaque page rendue et écrite.
• Deux raisons de plus de recharger. Une entrée absolue de coverageFile.paths hors de l’espace de travail — un arbre de build à côté de la copie de travail, une racine de sortie Bazel — est désormais interrogée elle aussi, si bien qu’un fichier qui y apparaît après l’ouverture de la fenêtre est chargé au lieu de ne plus jamais être regardé ; l’observateur ne voyait jamais que l’espace de travail. Et fuciniCoverage.watch.reloadAfterTasks nomme des tâches (un label de tasks.json, ou source: name tel que la liste Run Task l’affiche, p. ex. npm: test) dont la fin recharge la couverture, que watch.enabled soit activé ou non — pour les builds que l’observateur ne peut pas suivre : une exécution qui remplace un arbre de sortie lié symboliquement, un rapport sur un partage réseau, une étape de couverture qui post-traite son fichier.
• Espaces de travail multi-racines. Chaque dossier d’un espace de travail est désormais détecté selon ses propres termes : coverageFile.defaultLocation, coverageFile.paths, pathRemap, ignore, watch.*, remote.*, badge.*, les répertoires de rapport, gitDiff.*, problems.perLine, editorGutter.mode et hitCounts.inline sont lus par dossier, si bien que le .vscode/settings.json propre à un dossier ou son entrée dans le .code-workspace s’applique ; ${workspaceFolder} désigne le dossier de l’entrée elle-même ; les fichiers de trace trouvés dans chaque dossier fusionnent en une seule exécution, et la vue Coverage regroupe les fichiers par dossier. ${workspaceRoot} dans une règle pathRemap essaie d’abord le dossier du fichier de trace, puis les autres. Tout ce qui a besoin d’un seul dossier — les boîtes de dialogue de fichiers, la sortie du rapport et du badge, les métadonnées git, Run Tests with Coverage — prend celui de l’éditeur actif, et avec plusieurs dossiers sans éditeur, l’exécution des tests demande lequel. Un dossier ajouté à l’espace de travail ou retiré de celui-ci recharge la couverture de lui-même. Auparavant, douze endroits prenaient le premier dossier, et une seconde racine obtenait une mauvaise base pour tout.
• L’exécution est publiée dans la vue Test Coverage propre à VS Code. Avec fuciniCoverage.testCoverage.publish (activé par défaut), chaque exécution chargée va aussi dans le panneau Test Coverage natif, ses pourcentages par fichier dans l’Explorateur et la bascule « Show Inline Coverage » propre à l’éditeur — lignes, branches et fonctions, les détails étant chargés à la demande. Show in Test Coverage View publie l’exécution active et ouvre le panneau, quoi que dise le réglage ; le menu de la barre d’état le propose derrière quickActions.showTestCoverage.
• Une règle de remappage de chemins est suggérée quand les fichiers ne correspondent pas. Le « ça s’est chargé mais rien ne s’allume » le plus courant est un fichier de trace dont les chemins viennent d’un conteneur ou d’une copie de travail CI (/build/src/a.c, /home/runner/work/repo/repo/src/a.c, C:\agent\_work\1\s\src\a.c) alors que l’espace de travail contient src/a.c. Quand un chargement laisse des fichiers sans correspondance, l’extension cherche leurs noms dans l’espace de travail, infère la règle de préfixe qui en explique le plus grand nombre, la consigne sous [FUCINI_REMAP_002], et le résultat du chargement propose Apply Suggested Remap — un clic ajoute la règle à fuciniCoverage.pathRemap et recharge. Suggest Path Remap Rule lance la même analyse à la demande. Rien n’est écrit sans le clic.
• fuciniCoverage.ignore : des fichiers qui ne comptent jamais. Les fichiers vendorisés, générés ou tiers (vendor/**, **/*.generated.ts, build/**) sont écartés de l’exécution à son chargement, si bien que la vue Coverage, la barre d’état, les seuils, les badges, le CodeLens, l’historique et les exports comptent tous sans eux ; le résultat du chargement dit combien ont été laissés de côté et la sortie les nomme. Les motifs sont comparés au chemin relatif à l’espace de travail et au chemin absolu ; un motif sans / correspond à un nom de dossier ou de fichier à n’importe quelle profondeur, comme .gitignore. Pour des fichiers entiers — les lignes à l’intérieur d’un fichier continuent d’utiliser les marqueurs d’exclusion propres à l’outil.
• Entrées Problems par ligne, sur demande. fuciniCoverage.problems.perLine (off, uncovered ou uncoveredAndPartial ; désactivé par défaut) place un diagnostic Information sur chaque bloc contigu de lignes jamais exécutées — une fonction morte de quarante lignes est une entrée, pas quarante — et, dans le second mode, sur chaque ligne dont l’une des branches n’a jamais été prise. Uniquement pour les documents ouverts, si bien qu’une exécution de deux mille fichiers ne peut pas inonder le panneau ; les entrées suivent leurs lignes pendant l’édition du tampon et disparaissent à la fermeture du document. L’entrée par fichier derrière problems.enabled est inchangée.
• Un badge de couverture pour le README. Generate Coverage Badge écrit dans l’espace de travail un SVG de style shields pour l’exécution active (fuciniCoverage.badge.outputPath, par défaut coverage-badge.svg), qu’un README intègre avec ![coverage](coverage-badge.svg) sans aucun service hébergé. badge.metric choisit les lignes, les branches, le MC/DC ou le score pondéré ; la couleur suit les paliers de colorScale ; badge.autoUpdate le réécrit après chaque chargement. Le badge SVG qu’Export Coverage Report proposait déjà partage désormais le même moteur de rendu.
• Non mesuré et non couvert. Un fichier qu’aucun test n’a jamais chargé n’est pas du tout dans le fichier de trace, si bien que l’extension l’a toujours tenu à part d’un fichier mesuré avec 0 passage — et hors des chiffres, ce qui est exactement la façon dont un projet dont la moitié des modules n’a aucun test affiche « 92 % ». Désormais la distinction se voit : ouvrir un tel fichier place not measured dans la barre d’état, et fuciniCoverage.unmeasured.mode décide de la suite. list ajoute un groupe Unmeasured à la vue Coverage avec chaque fichier de l’espace de travail d’un type que l’exécution a mesuré mais qu’elle ne contient pas, les compte dans le résultat du chargement, les marque ? dans l’Explorateur quand les badges sont activés, et laisse threshold.unmeasuredFiles faire échouer Check Coverage Thresholds au-delà d’un nombre choisi. count va plus loin : chaque fichier de ce genre rejoint l’exécution à 0 % — une ligne non couverte par ligne de code — si bien que la barre d’état, les seuils, les badges, l’historique, les exports et la vue Test Coverage voient tous le chiffre honnête ; le fichier est dessiné partout comme non mesuré, jamais comme « ne correspond plus à sa couverture ». unmeasured.exclude en écarte les en-têtes et assimilés (**/*.h, **/*.hpp, **/*.hh, **/*.inl, **/*.d.ts par défaut). Désactivé par défaut ; l’état de la barre d’état est le seul changement toujours actif.
• La vue Couverture montre ce que la fusion a fait. Depuis 0.2026.63, la réexécution propre d’un module chargée par-dessus une exécution du projet entier remplace les chiffres de celle-ci pour les fichiers du module, et chaque ligne nommait le rapport dont elle provient — mais une ligne dont les chiffres avaient supplanté un rapport plus ancien ressemblait exactement à une ligne mesurée par un seul rapport parmi plusieurs, et rien ne disait quelle part d’un rapport avait été supplantée. Désormais le badge de tracefile d’une telle ligne est entouré ; chaque ligne de tracefile au-dessus de l’arbre compte ce que la fusion a fait de ses fichiers (« 42 fichiers · 7 supplantés par un rapport plus récent », « 7 fichiers · supplante 7 dans des rapports plus anciens ») ; et un clic sur une ligne de tracefile met en évidence les fichiers qu’elle a mesurés dans l’arbre complet, en atténuant les autres, jusqu’au clic suivant. fuciniCoverage.coverageView.mergedMarks (activé par défaut) désactive le contour et la mise en évidence ; les comptes restent.

Corrigé

• Un utilisateur Business ou Enterprise se voit désormais demander son code d’invitation, et non le code d’entreprise. Depuis le 2 septembre, le serveur de licences refuse le code d’entreprise partagé pour un siège Business ou Enterprise : un siège réclamé avec lui ne nommait personne, si bien que chaque siège d’équipe est désormais lié à l’adresse à laquelle il a été invité, et le code qui en active un est le code d’invitation FCI1… de cet e-mail. Le questionnaire, lui, intitulait encore le champ « Code d’entreprise », suggérait de le demander au responsable et affichait un exemple FCB1… — envoyant les gens coller le seul code qui ne fonctionne plus, puis leur demandant de saisir un code d’entreprise quand ils laissaient le champ vide. Dans les offres d’équipe, le champ s’intitule maintenant « Code d’invitation », l’indication dit d’où vient le code et que le code d’entreprise partagé n’active pas de siège, l’exemple montre la forme FCI1…, et le message de validation demande le code d’invitation. Pro demande son code d’abonnement sous ce nom. Pro Plus est inchangé : il conserve le code partagé à dessein. Les 17 langues d’affichage portent la nouvelle formulation.

Corrigé

• ${workspaceFolder} fonctionne désormais dans coverageFile.paths, comme il l’a toujours fait dans coverageFile.defaultLocation. Les deux réglages sont côte à côte et un seul documentait la variable, si bien qu’on l’écrivait dans les deux — or une entrée commençant par ${ n’est pas absolue : elle entrait donc littéralement dans le glob de recherche sous le dossier de base, ne trouvait rien, et l’extension annonçait qu’il n’y avait pas de couverture. Une telle entrée est maintenant développée d’abord, ce qui en fait un chemin absolu, puis simplement vérifiée. Elle reste telle qu’écrite dans le réglage, n’est pas réécrite une seconde fois sous une autre forme quand le même fichier est choisi, et sort d’elle-même du réglage quand on la décharge depuis la vue Coverage.
• Un fichier de trace configuré mais absent est désormais signalé dans la sortie. Une entrée au chemin erroné échouait de la seule manière que rien ne signalait : « aucune couverture trouvée », impossible à distinguer d’un projet qui n’en a vraiment pas. [FUCINI_DISCOVERY] nomme maintenant chaque entrée pour laquelle aucun fichier n’a été trouvé et le chemin examiné, une fois par entrée plutôt qu’à chaque rechargement ; une entrée avec joker n’est pas signalée, car elle peut attendre qu’un build écrive quelque chose.

Ajouté

• Le CodeLens par fonction affiche désormais les branches, le MC/DC et un score composite, pas seulement les lignes et les passages — « add : 92 % couvert (12/13 lignes, 52 passages, score 88 %, branches 3/4 (75 %), MC/DC 2/3 (66 %)) ». Chacun est omis pour une fonction où le fichier de couverture n’a rien à en dire — un build en C pur sans données de branches, ou un build non instrumenté avec -fcoverage-mcdc — plutôt que d’afficher un 0/0 trompeur ; le score n’apparaît de même qu’à côté d’au moins un des deux autres, puisqu’avec les lignes pour seule métrique il est par définition le nombre même par lequel la lentille commence déjà.
• L’infobulle de la pastille d’origine dit depuis combien de temps chaque fichier de couverture a été écrit, pas seulement son horodatage — « Mesuré par module.info (2026-08-15 14:32 · il y a 3 heures), remplaçant ce que lcov.info (2026-08-01 09:10) en disait. » Les paliers descendent jusqu’à « à l’instant » ; au-delà de 30 jours, seule la date absolue est affichée.
• Une égalité de mtime entre fichiers de couverture n’est plus silencieuse. Deux rapports produits à la même étape de build, ou un système de fichiers dont la résolution de mtime est plus grossière que la seconde, peuvent donner un horodatage identique à des fichiers qu’ils mesurent tous deux — jusqu’ici, le gagnant retombait sur l’ordre de coverageFile.paths sans rien à l’écran pour l’expliquer. Le canal de sortie le dit désormais : [FUCINI_MERGE_TIE] nomme les deux fichiers de couverture et le nombre de fichiers qu’ils ont en commun.
• « Show What Changed Since Last Run » dans le menu … d’une ligne de fichier, dès qu’une exécution précédente existe pour la comparaison — le même delta par fichier que Compare with Last Run calcule déjà, visant le seul fichier demandé plutôt que l’arbre entier. Un fichier où rien n’a bougé le dit clairement plutôt que de ne rien proposer.
• Commande Tune Colour Scale : essayez des couleurs et des seuils colorScale.* sur la vue Coverage en direct avant de vous y engager. Chaque modification s’écrit directement dans le réglage — la vue se redessine déjà à tout changement de colorScale/threshold, donc écrire la valeur est l’aperçu — et un « Conserver » ou « Revenir aux valeurs d’origine » final boucle la boucle.
• Les lacunes de couverture par fichier dans le panneau Problems, une entrée par fichier source chargé sous threshold.statement, derrière le nouveau fuciniCoverage.problems.enabled (désactivé par défaut — le seuil d’instructions par défaut est 100). Chaque entrée résume ce qui n’est pas couvert (« 62 % de lignes couvertes — 14 lignes non couvertes, 2 fonctions non couvertes ») et porte un correctif rapide qui ouvre l’extension de chat installée (Copilot, Claude Code, …) avec une invite à écrire un test pour la lacune — un diagnostic par ligne inonderait Problems sur une vraie base de code, donc cela reste au niveau du fichier, celui sur lequel un lecteur peut réellement agir.

Corrigé

• La raison d’un fichier absent, non concordant ou vérifié, dans la vue Coverage, peut désormais être sélectionnée et copiée. Elle ne vivait jusqu’ici que dans l’infobulle title native de la ligne, laquelle — étant celle du navigateur — ne se sélectionne pas ; qui voulait coller la raison exacte dans un rapport de bug devait la retaper à la main. Le survol affiche maintenant le même texte dans un vrai panneau stylé, que l’on peut balayer à la souris comme tout autre contenu de la page. L’infobulle d’un fichier ordinaire (son seul chemin) est inchangée.
• Une fonction dont la liste de paramètres s’étend sur plusieurs lignes n’est plus signalée à tort comme déplacée. detectMismatch tolérait que la ligne enregistrée d’une déclaration s’écarte d’au plus deux lignes de l’endroit où son nom est réellement trouvé — assez pour le désaccord habituel entre une ligne de signature, une ligne de type de retour et une accolade ouvrante, mais pas pour une liste de paramètres multiligne, qui peut éloigner les deux arbitrairement. void LOG_Emit(...) — sept paramètres, un par ligne — enregistrée à son accolade ouvrante, ligne 163, était signalée comme "LOG_Emit" is at line 3 : la correspondance textuelle la plus proche, qui se trouvait être le nom de la fonction elle-même mentionné dans le commentaire d’en-tête du fichier, loin de la ligne 163 comme de la vraie déclaration en ligne 156. La vérification accepte désormais aussi un nom trouvé plus haut lorsque chaque ligne entre lui et la ligne enregistrée se lit comme une seule déclaration ininterrompue — pas de ligne vide, pas de ligne terminant l’instruction ou le bloc précédent — ce qu’une liste de paramètres fait toujours et une fonction réellement déplacée presque jamais. Là où une non-concordance reste réelle, la ligne signalée est désormais la correspondance la plus proche de celle enregistrée, plutôt que toujours la première trouvée dans le fichier.
• La pastille d’origine ne dit plus « +N ». Charger le rapport propre d’un module par-dessus une exécution plus large marquait la pastille du fichier du nom du module plus le nombre d’autres fichiers de couverture qui le couvraient aussi — voulu comme « autant ont été supplantés », cela se lisait comme « ces rapports sont d’accord », et rien dans l’arbre ne permettait de savoir lesquels des n étaient visés. La pastille ne nomme plus jamais que le fichier de couverture dont les chiffres sont à l’écran ; l’infobulle détaille toujours ce qui a été supplanté, et par quoi.
• La pastille d’origine ne pousse plus le nom de fichier qu’elle côtoie hors du bord du panneau. La largeur de la pastille était fixe (flex: none), si bien que dès qu’une ligne manquait de place, le nom de fichier absorbait tout le déficit et se tronquait le premier, alors que la pastille est la moins importante des deux. La pastille cède désormais sa propre largeur avant que le nom de fichier ne perde un seul caractère ; le pourcentage et la barre, qui priment déjà sur le nom de fichier, ne sont pas concernés.

Modifié

• La réexécution propre d’un module remplace ce qu’une exécution plus large en disait, au lieu de s’y ajouter. Charger un rapport couvrant tout le projet, puis par-dessus le rapport propre d’un seul module, additionnait jusqu’ici leurs passages pour chaque fichier commun aux deux — une réexécution des seuls tests de ce module gonflait des chiffres qu’une exécution plus large, désormais périmée, avait déjà rapportés, au lieu de les rafraîchir. Le fichier de couverture au mtime le plus récent sur le disque l’emporte désormais sans partage pour tout fichier qu’il mesure : instructions, branches, déclarations et les cumuls par fichier (résumés de branches, MC/DC, fonctions, appels de fonctions, code objet et mutations) proviennent tous de ce seul rapport, quelle que soit la position de l’un ou l’autre chemin dans coverageFile.paths — une réexécution de module gagne parce qu’elle est réellement plus récente, pas parce qu’elle se trouve chargée en dernier. Un fichier de couverture qui ne rapporte aucune instruction pour un fichier — un export de code objet TRACE32, un rapport de mutations Stryker chargé à côté d’un vrai — n’apporte toujours que le résumé qu’il porte réellement, laissant intact le détail des lignes et des branches d’un rapport antérieur ; ce cas est inchangé. Cela supprime aussi un défaut de longue date où un cumul MC/DC (ou fonctions, appels de fonctions, mutations) par fichier mesuré par deux exécutions voyait son dénominateur additionné avec son numérateur, sous-estimant le vrai pourcentage. L’infobulle de la pastille d’origine dit désormais « remplaçant ce que _ en disait » plutôt qu’« additionnés ».

Corrigé

• Un nom de fichier long dans la vue Coverage est désormais tronqué au lieu de déborder. Le span du nom dans la ligne n’avait pas min-width: 0, la seule déclaration qui laisse l’overflow/text-overflow: ellipsis d’un élément flex s’appliquer vraiment — sans elle, un nom long gardait toute sa largeur dès que le panneau devenait assez étroit, et passait sous la pastille d’origine, le pourcentage et la barre qui le suivent.

Ajouté

• Triez la vue Coverage par score, pas seulement par nom. Chaque ligne porte déjà un score WHM et une répartition par métrique ; trouver le pire fichier d’un grand arbre, c’était le chercher en descendant une liste alphabétique. Une liste déroulante à côté de Collapse all / Expand all propose désormais Nom de fichier, Score composite, Lignes, Branches et MC/DC — chaque mode sauf Nom de fichier entremêle dossiers et fichiers, les pires d’abord selon le pourcentage propre à cette métrique, de sorte qu’un dossier mal testé se classe exactement comme un fichier mal testé au lieu d’en être regroupé à l’écart. Un fichier sans données pour la métrique choisie (un format qui ne rapporte jamais de branches, par exemple) se trie en bas plutôt que d’être lu comme un 0 %. Le choix est écrit dans le nouveau réglage fuciniCoverage.coverageView.sortBy au moment où il est fait, si bien qu’il survit à un rechargement de la fenêtre au lieu de toujours repartir de Nom de fichier.

Corrigé

• Une signature de fonction multiligne n’est plus signalée à tort comme « déplacée ». Le fnMap d’Istanbul donne à une fonction deux références de ligne — où se trouve son nom, et où commence son corps — et l’analyseur préférait la ligne du corps pour la vérification de concordance qui cherche ensuite le nom dans le texte source. Pour toute fonction dont la liste de paramètres s’étend sur plus de deux lignes (courant dans une base de code repliée à 100 colonnes), la vraie ligne du nom était trop loin de celle enregistrée, et le fichier s’estompait dans la vue Coverage avec un faux avertissement « ne correspond plus à sa couverture ». L’analyseur préfère désormais la ligne du nom lui-même, ce que la vérification de concordance a toujours cherché.

Ajouté

• Chaque ligne indique quel fichier de couverture l’a mesurée. Charger le rapport d’un module par-dessus une exécution couvrant tout le projet, ce sont les mêmes fichiers mesurés deux fois, et l’arbre ne disait rien du rapport que lisait une ligne. Avec plusieurs fichiers chargés, chaque ligne porte désormais le nom du rapport qui l’a mesurée — le dernier chargé lorsqu’il y en a eu plusieurs — avec +1 pour chacun des autres et une infobulle qui les nomme. Une fusion additionne leurs passages au lieu d’en faire gagner un, et l’infobulle le dit. Avec un seul fichier, rien n’est dessiné : il n’y aurait rien à distinguer.

Modifié

• La page de l’extension nomme chaque réglage, avec sa vraie valeur par défaut. Vingt réglages n’avaient aucune ligne — la langue, trois seuils, un poids et les quinze interrupteurs d’actions rapides — et la ligne de télémétrie annonçait une valeur par défaut activée alors qu’elle est désactivée depuis un moment. Un test compare désormais la page au manifeste, valeurs par défaut comprises.

Corrigé

• La revérification des sources sous files.watcherExclude, ajoutée dans la version précédente, obéit désormais à staleWarning.enabled comme le reste de cette vérification, et non à un nom de réglage qui lui serait propre.

Modifié

• L’Explorateur est laissé tranquille. Les pastilles de couverture à côté des fichiers y sont désactivées par défaut. Cette colonne appartient à qui s’en sert — VS Code y place les M et U de git, et une seule pastille tient — et la vue Couverture liste les mêmes fichiers avec les mêmes chiffres, à un endroit prévu pour eux. explorerBadges.enabled les rétablit à l’identique.

Corrigé

• Une source sous files.watcherExclude est revérifiée aussi. La correspondance en direct entre un fichier et sa couverture repose sur les enregistrements et sur un observateur du système de fichiers, muet pour tout ce qui est exclu — surtout les sources générées sous build/, là où une marque périmée est la plus difficile à voir. Ces fichiers sont désormais interrogés au même rythme de deux secondes que les fichiers de couverture, et relus seulement lorsqu’ils ont vraiment bougé. Au-delà de deux cents, la sortie le dit plutôt que d’y passer le tour d’horloge.

Ajouté

• On demande le lanceur de tests une fois, pas à chaque exécution. Un espace de travail avec plusieurs lanceurs reconnus — une configuration jest et un go.mod, par exemple — plaçait le sélecteur devant chaque Run Tests with Coverage, réclamant une frappe pour une décision déjà prise. La réponse est désormais mémorisée pour l’espace de travail, et l’invite le dit. Forget the Test Runner remet la question, et un lanceur mémorisé que l’espace de travail n’a plus est ignoré plutôt qu’exécuté.

Modifié

• La page de l’extension nomme chaque commande. Quatorze des trente-quatre avaient glissé hors de son tableau — documentées ici et dans le guide, mais pas sur la page que l’on lit avant d’installer. Toutes y figurent désormais, et un test l’y maintient.

Corrigé

• Annuler retire à nouveau les points des lignes modifiées. Un tampon modifié depuis l’exécution affiche des points gris sur les lignes réécrites, et la couverture s’en retire. Annuler ces modifications laissait les points en place : chaque changement comptait, y compris celui qui remettait le texte. Ce que le tampon contenait avant la première frappe est désormais mémorisé, et dès qu’il le contient à nouveau, les points disparaissent et les chiffres s’y appliquent de nouveau.
• Les numéros de version sont vérifiés les uns par rapport aux autres. Le manifeste, l’entrée du haut du journal et l’étiquette de version portent la version et le build, tous trois saisis à la main, et ils ont déjà divergé. La suite de tests les compare et vérifie que les entrées vont du plus récent au plus ancien, chacune avec une vraie date.

Modifié

• Un fichier de couverture déchargé le reste. Retirer un fichier de la liste de la vue Couverture durait exactement le temps de la fenêtre : sans configuration, la détection revient aux noms connus et retrouvait lcov.info le lendemain matin, et la seule façon de dire autre chose était de configurer un chemin pour en exclure un. Cette décision est désormais mémorisée pour l’espace de travail. Elle est annulée en choisissant à nouveau le fichier ou en le nommant dans coverageFile.paths — un fichier que le réglage nomme n’est jamais retenu, donc rien ne peut manquer sans que quelqu’un l’ait dit.

Corrigé

• Redessin plus rapide d’un tampon modifié. La liste des lignes réécrites était recalculée à partir de toutes les modifications enregistrées à chaque redessin : un long fichier modifié tout l’après-midi payait le nombre de lignes fois le nombre de modifications pour une réponse inchangée depuis la dernière frappe. Elle est désormais calculée une fois par frappe.

Modifié

• Une exécution de tests retient son fichier de couverture, comme un choix manuel. Run Tests with Coverage chargeait ce que l’exécution avait écrit, puis demandait s’il fallait l’ajouter à coverageFile.paths. Un fichier choisi à la main y est écrit tout seul depuis 0.2026.56, et une exécution de tests est le même geste par une autre voie : elle l’écrit donc de la même façon. Un seul réglage, coverageFile.rememberPicks, gouverne les deux ; la ligne du fichier dans la vue Couverture est l’endroit où l’un comme l’autre se retire.

Corrigé

• Les minuteries d’arrière-plan s’arrêtent avec l’extension. L’observateur du fichier de couverture était libéré avec la fenêtre, mais l’interrogation de deux secondes derrière lui et toute revérification de source en attente sont de simples minuteries, que rien ne libère. Désactiver l’extension, ou recharger une fenêtre avec l’extension désactivée, les laissait tourner et lire un espace de travail que l’extension n’avait plus à lire.

Ajouté

• L'aperçu en direct dit ce qu'il montre. L'aperçu du panneau des paramètres commence désormais par Exécution : coverage/lcov.info · 12 fichiers et, quand l'éditeur actif montre un fichier couvert par l'exécution, par Fichier actif : src/a.c avec le verdict propre de ce fichier sous celui de l'exécution. Il suit l'éditeur et chaque chargement, selon ce que contient le formulaire — modifications non enregistrées comprises. Le panneau au premier plan, un clic dans la vue Couverture bascule l'aperçu sur ce fichier au lieu de l'ouvrir.
• Le sélecteur nomme chaque format. Tous les formats de couverture d'abord, puis 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) ; profil de couverture Go ; listing gcov et Testwell CTC++ — et .lcov, .gcov, .txt et .coveragexml ne sont plus grisés.

Modifié

• Les survols de la barre d'état portent l'échelle de couleurs. Les barres de métriques des infobulles d'exécution et de fichier prennent les trois couleurs de colorScale.*, réparties selon le seuil propre de chaque métrique quand il est configuré et selon les paliers de l'échelle sinon ; les pastilles de verdict gardent leurs couleurs d'état fixes.
• Des drapeaux dessinés dans le paramètre de langue. Les émojis de drapeaux de 0.2026.56 s'affichent sous Windows comme deux lettres nues. La liste nomme désormais chaque langue par son propre nom — Nederlands (nl) — avec, en dessous, une rangée de petits drapeaux dessinés qui sélectionnent dans la liste.

Ajouté

• Un choix est mémorisé. Un fichier choisi avec Pick Coverage File ne vivait que dans la fenêtre où il avait été choisi. Il va désormais tout seul dans coverageFile.paths des paramètres de l'espace de travail — relatif au dossier de base s'il est en dessous, absolu sinon — de sorte que la fenêtre suivante le charge et que le surveillant le recharge. coverageFile.rememberPicks (activé par défaut) conserve l'ancien comportement pour qui le souhaite. Une entrée absolue dans ce paramètre nomme désormais un fichier où qu'il soit.
• Fichiers de trace dans la vue Couverture. Au-dessus de l'arbre, une ligne par fichier de trace chargé, avec son nombre de fichiers et un bouton de déchargement qui le retire de l'exécution et des paramètres ; un bouton Choisir… à côté en ajoute un. Décharger le dernier fichier de trace efface l'exécution.
• Des drapeaux dans le paramètre de langue. La liste des langues du panneau des paramètres montrait des codes nus ; chaque entrée porte désormais un drapeau et le nom de la langue dans sa propre langue — 🇳🇱 Nederlands (nl), 🇯🇵 日本語 (ja), 🌐 Automatique.

Corrigé

• La dernière ligne d'un fichier PHP ne compte plus comme couverture au-delà de la fin. Xdebug et PCOV enregistrent le return implicite de fin de fichier sur la ligne qui suit le dernier saut de ligne, de sorte que php-code-coverage écrit un passage sur la « ligne 252 » d'un fichier de 251 lignes — et la vérification de non-concordance appelait cela une contradiction, sur chaque fichier PHP se terminant par un saut de ligne. Une ligne au-delà d'un saut de ligne final est désormais admise ; une référence plus loin, ou au-delà d'un fichier sans saut de ligne final, reste la contradiction qu'elle était.

Ajouté

• Une ligne d'essai dans What Community Includes, dans l'édition Community. Cette version n'a jamais eu d'essai, sa liste commence donc désormais par Démarrer un essai Pro de 14 jours…, qui ouvre la fiche Pro ; l'activation de la version Pro propose ensuite d'écarter la version Community. Community reste gratuit quoi qu'il soit décidé.

Ajouté

• Show Worst-Covered Folders. La réponse au niveau des dossiers à Show Worst-Covered Files : chaque dossier classé par la couverture de tout ce qu'il contient, du pire au meilleur, à partir du même index que les badges de l'Explorateur ; un choix révèle le dossier dans l'Explorateur. Dans le menu de la barre d'état avec quickActions.worstCoveredFolders.

Ajouté

• Le contrôle de seuils dans le panneau Problèmes. Avec compliance.diagnostics activé, chaque métrique threshold.* non atteinte est une erreur dans Problèmes, sur le fichier de trace qui l'a manquée, rafraîchie à chaque chargement et par Check Coverage Thresholds, effacée dès que le contrôle passe. Désactivé par défaut, car le seuil d'instructions livré est 100.

Modifié

• La description de watch.enabled ne promet plus de question. Elle disait encore que l'édition gratuite est interrogée avant un rechargement — vrai jusqu'à 0.2026.48, plus depuis. Réécrite dans les 18 langues.

Ajouté

• Run Tests with Coverage. Reconnaît vitest, jest, pytest, go, cargo, dotnet, maven, gradle, phpunit ou ctest à la racine de l'espace de travail, l'exécute avec la couverture activée dans une tâche de terminal, charge ce qu'il a écrit que les tests aient réussi ou non, et propose une fois d'ajouter ce chemin à coverageFile.paths pour que le surveillant fasse désormais le chargement. Plusieurs lanceurs sont proposés au choix ; aucun ne vous renvoie aux recettes.

Ajouté

• La couverture suit le texte dans un tampon modifié. Les modifications de chaque tampon ouvert depuis le chargement de l'exécution sont conservées, et chaque surface qui lit les numéros de ligne de l'exécution — le nombre de passages au survol, la barre MC/DC, le triangle « depuis la dernière exécution », le CodeLens, Next Uncovered — lit à travers elles : une marque suit sa ligne et se retire d'une ligne réécrite, où un petit point gris dit pourquoi. dirtyMarks.enabled désactive les points.

Ajouté

• Depuis la dernière exécution, dans la gouttière. Chaque ligne exécutée lors de l'exécution précédente et pas dans celle-ci porte un triangle rouge dans la gouttière de l'éditeur, chaque ligne ayant fait le chemin inverse un vert, chacun avec une bande dans la règle d'aperçu et les nombres de passages au survol. Les lignes inchangées n'affichent rien. sinceLastRun.enabled le désactive.

Modifié

• La référence de la « dernière exécution » survit à un redémarrage. Avec history.enabled activé, l'exécution la plus récente de l'historique tient ce rôle au premier chargement d'une fenêtre, de sorte qu'une compilation terminée avant l'ouverture de la fenêtre montre encore ce qu'elle a changé — dans la gouttière et dans Compare with Last Run.

Ajouté

• Le verdict sur un fichier reste à jour après le chargement. Un fichier était vérifié une fois par rapport à sa couverture, au chargement du fichier de trace, puis plus jamais : modifiez-le tout un après-midi et les gouttières continuaient d'afficher des chiffres sur une version qui n'existait plus. Désormais un enregistrement dans l'éditeur revérifie ce fichier aussitôt, et une modification hors de l'éditeur — un git checkout, un formateur, un générateur — le revérifie depuis le disque un instant plus tard. Un fichier qui vient contredire son exécution reçoit la marque ; un checkout qui remet la version mesurée l'efface.
• La différence exacte, au survol. Là où un fichier ne correspond plus à sa couverture, la vue Couverture et l'infobulle de l'Explorateur disent précisément ce qui l'a prouvé : la ligne telle qu'elle se lit maintenant face à ce que le rapport avait enregistré quand le fichier de trace conservait le texte, la ligne et une somme de contrôle en échec quand il conservait une empreinte, une couverture au-delà de la fin du fichier, une fonction qui n'est plus là où le rapport la place. Le même détail va dans le canal de sortie, une ligne par fichier, où mène Afficher lesquels sur le résultat du chargement.
• Un interrupteur pour les badges de l'Explorateur. explorerBadges.enabled (activé par défaut) masque le score, ✓ et ⚠ à côté de chaque fichier couvert dans l'Explorateur, ainsi que l'infobulle par métrique. Gouttières, barre d'état et vue Couverture ne changent pas.

Modifié

• Chaque édition recharge d'elle-même quand le fichier de trace change. Depuis le 2026-09-02, l'édition gratuite s'arrêtait à une question nouvelle couverture détectée — la charger ? tandis que les licences payantes rechargeaient en silence. Une compilation se termine, les chiffres sont nouveaux, et qui a activé la surveillance a déjà répondu à la question — la question a donc disparu sur chaque édition, et l'avis qui l'expliquait avec elle.
• Les chargements que le produit fait de lui-même ne comptent plus dans le plafond quotidien de l'édition gratuite. Un rechargement par le surveillant ou la découverte au démarrage n'est pas un chargement que quelqu'un a demandé ; les compter aurait épuisé le quota d'une installation Community en une matinée de tests, puis laissé une ancienne exécution à l'écran sans rien pour le dire. Le plafond ne mesure plus que la commande et le sélecteur.
• Un horodatage modifié ne suffit plus à signaler un fichier. L'avertissement N fichier(s) modifié(s) depuis cette exécution venait de la mtime de chaque source, et un git pull ou un formateur modifie chaque mtime sans changer ce qui a été mesuré. Il a disparu, avec sa marque dans la barre d'état. Un fichier n'est désormais dit modifié que lorsque son contenu contredit l'exécution, et la barre d'état, le résultat du chargement et une nouvelle ligne de sortie FUCINI_MISMATCH_001 lisent tous cela. staleWarning.enabled garde son nom et décrit maintenant exactement la vérification du contenu.
• Surveiller un dossier sous files.watcherExclude est dit dans la sortie. La sortie de compilation est la première chose que l'on exclut du surveillant de VS Code, après quoi seul le sondage toutes les 2 s remarque une nouvelle exécution. Le canal de sortie nomme désormais le dossier et le glob au démarrage du surveillant.

Ajouté

• Un indice au premier lancement pour un espace de travail sans rien à charger. La surveillance est active par défaut et le chargement au démarrage est silencieux, si bien qu'une installation neuve dans un projet sans fichier de trace ne disait rien du tout. Le premier chargement silencieux qui revient vide le dit désormais — une fois, pour toujours — avec les deux choses qui valent la peine : choisir un fichier de couverture à la main, ou ouvrir les recettes pour en produire un avec votre chaîne d'outils. Un chargement lancé à la main garde son propre message.
• Des touches pour Toggle Annotated Source et Load Coverage. Alt+A bascule l'onglet actif entre la source et sa vue annotée ; Alt+Shift+R redécouvre et recharge la couverture (Ctrl+Alt+A / Ctrl+Alt+R sous macOS). Réaffectables comme les deux ajoutées en 0.2026.45.

Modifié

• Les chemins qui ne correspondent à rien dans l'espace de travail sont comptés à l'écran. Un chemin de fichier de trace qui ne se résout vers aucun fichier de l'espace de travail se charge et ne s'allume jamais — le « ça a marché mais rien ne s'affiche » le plus courant qui soit — et jusqu'ici la seule trace en était une ligne FUCINI_REMAP_001 dans le canal de sortie, avec la règle pathRemap qui le corrigerait, non lue. Le résultat du chargement les compte maintenant, avec Lesquels ? pour les noms et la règle suggérée, et Ouvrir le réglage pathRemap pour l'endroit où la mettre.
• Le sélecteur de fichier du menu de la barre d'état nomme les formats qu'il lit. Sa description listait encore les cinq formats de la première version ; elle en annonce désormais vingt-cinq, de lcov, Cobertura et JaCoCo à gcov, llvm-cov, TRACE32 et aux rapports de mutation.

Modifié

• Les deux éditions installées : deux boutons au lieu d'instructions. Avec Pro et Community présents ensemble, aucune ne peut s'activer — elles définissent les mêmes commandes et les mêmes vues — et le message qui le disait se terminait par un itinéraire vers la vue Extensions. Les deux remèdes tiennent en une commande chacun, alors ce sont désormais des boutons : Garder celui-ci désinstalle l'autre édition et propose le rechargement ; Afficher les deux dans Extensions ouvre la vue Extensions exactement sur ces deux-là. Si la désinstallation échoue, le rechargement est quand même proposé — c'est lui qui tranche quelle édition est active.
• Un plafond d'utilisation est annoncé en entier une fois, puis seulement dans la barre d'état. La première fois qu'un plafond Community est atteint, il mérite la réponse complète — les chiffres, l'offre, le déblocage par télémétrie, la liste de ce que l'offre inclut. La cinquième fois, dix minutes plus tard, non. Au cours d'une session, les atteintes suivantes du même plafond placent une ligne de huit secondes dans la barre d'état et n'interrompent rien. Saisir une clé repart de zéro, car une nouvelle licence est un nouveau jeu de plafonds.

Ajouté

• Next / Previous Uncovered ont des touches. Ce sont les deux commandes qu'on presse encore et encore en lisant un fichier, et jusqu'ici chaque pression signifiait ouvrir la palette de commandes et taper le nom. Alt+N passe à la plage non couverte suivante et Alt+P à la précédente (Ctrl+Alt+N / Ctrl+Alt+P sous macOS, où Option saisit des caractères). Les deux ne valent que dans un éditeur de texte actif et se réaffectent sous Keyboard Shortcuts comme n'importe quel autre réglage par défaut.

Ajouté

• Ce que Community inclut, en une seule liste. L'offre gratuite plafonne huit actions et retient douze fonctionnalités, et chacune de ces décisions était appliquée à sa propre porte — la seule façon d'apprendre la forme de l'offre était donc de buter sur chaque mur l'un après l'autre, en pleine tâche. Une nouvelle commande, What Community Includes, montre tout d'un coup : chaque action plafonnée avec la part du jour ou du mois déjà consommée, chaque fonctionnalité retenue par son nom, et les deux façons de lever tout cela — une offre payante, ou le déblocage par télémétrie.
• Proposé partout où la question se pose. Une entrée dans le menu de la barre d'état, un bouton dans la bannière de licence de la vue Coverage, et un bouton sur les deux messages qu'une installation Community rencontre devant un mur — limite d'utilisation atteinte et cette action n'est pas incluse. Les lignes sont dérivées du même jeu de droits que les garde-fous appliquent, donc ce que la liste dit est ce qui arrivera.

Modifié

• Le mode surveillance dit ce qu'il fera sur l'offre gratuite. L'entrée de la barre d'état promettait à tous de « recharger automatiquement la couverture », et sur Community c'est une promesse que le surveillant ne tient pas — il remarque, et demande. L'entrée le dit désormais, et la commande s'appelle Toggle Tracefile Watch, puisque « Toggle Watch » ne disait jamais ce qui était surveillé. Le comportement lui-même est inchangé.

Modifié

• Un fichier de trace qui ne se charge pas dit désormais pourquoi, et quoi essayer. Chaque échec produisait la même notification — « no coverage could be parsed. See output. » — avec la raison un canal plus loin, sous forme de code et de message de l'analyseur. La notification commence maintenant par le fichier et classe le refus selon ce qu'il était : pas dans un format lu par cette extension, mal formé (une compilation qui l'écrivait encore est la cause habituelle), bien formé mais sans rien d'enregistré (l'exécution n'a exécuté aucun code instrumenté), ou illisible. Les mots de l'analyseur lui-même suivent, plusieurs fichiers sont comptés, et le canal de sortie est proposé derrière un bouton Afficher la sortie plutôt qu'ouvert de force.
• Les fichiers qu'un fichier de trace liste mais où il n'y a rien à mesurer sont désormais comptés à l'écran. Un en-tête ne contenant que des déclarations a toujours été tenu hors de la vue Coverage plutôt que noté 100 % sur 0 de 0 — et son nom était écrit dans le canal de sortie, et nulle part ailleurs. Le résultat du chargement dit maintenant N fichier(s) sans rien à instrumenter ne sont pas affichés, avec un bouton Lesquels ? qui ouvre le canal où sont les noms.

Ajouté

• NCover et JetBrains dotCover. Le Cobertura de Coverlet et OpenCover étaient déjà lus ici, ce qui couvre l'essentiel du nouveau travail .NET et rien de l'ancien genre. Une build écrivant encore le Coverage.xml de NCover, ou une équipe mesurant avec dotCover, avait une couverture sur disque que cette extension ne pouvait pas ouvrir. Aucun des deux formats n'a besoin de convertisseur : les deux portent déjà des noms de fichiers et des numéros de ligne.
• Un point NCover exclu est écarté, pas compté comme non exécuté. excluded="true" marque du code délibérément retiré de la mesure — un membre avec [ExcludeFromCodeCoverage], ou un filtre NCoverExplorer. Le compter comme non couvert ferait qu'une exclusion abaisse le nombre qu'elle était censée corriger.
• dotCover a besoin de /ReportType=DetailedXML. Son autre rapport XML est un cumul sans aucun numéro de ligne ; ce rapport est reconnu et refusé avec l'indication du drapeau qui corrige cela, plutôt que d'échouer comme format inconnu. dotCover n'enregistre qu'un oui ou un non par instruction, jamais un nombre de visites, donc une instruction couverte donne un seul hit.

Ajouté

• Tests de mutation. La couverture dit qu'une ligne a été exécutée ; un score de mutation dit que quelque chose a échoué quand cette ligne a été modifiée. Une suite peut exécuter chaque ligne d'un fichier sans détecter aucun des défauts injectés, et aucun chiffre de couverture ne le dira. PIT couvre Java, Kotlin et Scala ; Stryker couvre JavaScript, TypeScript, C# et Scala.
• Il n'est jamais moyenné avec la couverture. Mélanger « cette ligne a-t-elle tourné » avec « quelque chose l'a-t-il remarqué quand je l'ai changée » ne répond à aucune des deux, donc il n'a aucun poids dans le score composite et est contrôlé séparément via fuciniCoverage.threshold.mutation — à 0 par défaut, car un score de mutation est un objectif à améliorer, pas une barre à franchir dès le premier jour.
• Un mutant n'ayant jamais eu d'exécution équitable ne compte dans aucune des deux moitiés. Le NON_VIABLE de PIT et les CompileError et Ignored de Stryker sont des mutations que l'outil n'a pas pu créer ; les compter comme non détectées pénaliserait une suite pour un défaut qui ne lui a jamais été proposé.

Ajouté

• Le listing annoté .gcov. gcov --json-format est arrivé avec GCC 9, et les compilateurs croisés embarqués sont souvent bien plus anciens ; jusqu'ici la réponse était d'installer d'abord lcov ou gcovr. Le compteur d'exécution a cinq graphies et seules deux sont des nombres, et les annotations branch/call/function appartiennent à la ligne voisine plutôt qu'à la leur — tout cela est désormais lu correctement.
• Les annotations d'appel deviennent une couverture par site d'appel. call N returned X% est exactement la métrique d'appel de fonction ajoutée en 0.2025.38, que ce format portait bien avant qu'il y ait ici un endroit où la placer.

Ajouté

• La couverture du code objet — quelle part du binaire construit s'est réellement exécutée. La seule métrique ici qui n'est absolument pas mesurée à la source : elle provient d'un débogueur observant le flux d'instructions sur la cible réelle, sans aucun effet de sonde sur le timing. C'est aussi la réponse honnête à la question "cela couvre-t-il l'assembleur ?" — l'assembleur écrit à la main n'est jamais instrumenté, et aucune autre métrique ici ne peut l'atteindre.
• C'est une exigence, pas un poids supplémentaire. La couverture du code objet subsume la couverture des instructions — 100% ici implique 100% là, mais pas l'inverse — donc elle n'a aucun poids dans le score composite et est contrôlée à la place par un seuil, exactement comme le demande la DO-178C niveau A en plus de MC/DC.
• L'écart est le livrable. Une exécution à 100% de couverture de lignes et moins de 100% de couverture du code objet a localisé exactement le code produit par le compilateur dont votre source ne rend pas compte ; la fiche de conformité dit "312 octets jamais exécutés, avec 100% de couverture de lignes", plutôt que de l'enfouir sous "94%". Le cas inverse — un binaire entier déclaré exécuté alors que sa source ne l'était pas — est signalé comme une contradiction, pas comme un score faible.

Ajouté

• Couverture des appels de fonction — chaque site d'appel a-t-il été exercé. Une question différente de la couverture des fonctions : une fonction entrée une fois depuis l'un de ses trois sites d'appel est complète sous Fonctions et complète au tiers ici. VectorCAST, TRACE32 et Cantata rapportaient tous cela alors que ce modèle n'avait nulle part où placer le nombre.
• Cela complète VectorCAST et TRACE32. Les versions précédentes refusaient délibérément de replier ces données dans la couverture des branches, car gonfler un pourcentage de branches gonfle un nombre qui finit dans un audit. Les deux formats chargent maintenant ce qu'ils envoyaient depuis toujours.

Modifié

• La porte de conformité et le score pondéré connaissent désormais sept métriques, pas six — deux nouveaux réglages, fuciniCoverage.whmWeights.functionCalls et fuciniCoverage.threshold.functionCalls, avec des descriptions dans les 17 langues.

Modifié

• La couverture des fonctions compte désormais même quand l'outil ne dit pas où sont les fonctions. L'export func de TRACE32, les éléments <method> auto-fermants de VectorCAST, et le cumul method, % d'EMMA indiquent tous trois un nombre de fonctions sans nulle part où placer un CodeLens — les trois étaient écartés à l'entrée. Les déclarations restent la source préférée là où elles existent ; le nombre est désormais utilisé en repli là où il n'y en a pas.

Ajouté

• UCIS et UCDB XML — VHDL et Verilog, tout droit du simulateur. Deux documents répondent à ce nom, et un projet possède celui que son simulateur a écrit, donc les deux sont lus : la forme d'échange standard <UCIS> d'Accellera, et le ux:ucdb propre à Aldec, ce que produit réellement acdb2xml depuis Active-HDL et Riviera-PRO. La couverture des instructions et des branches passe ; la couverture toggle, FSM, assertion et fonctionnelle n'est pas lue, et un document ne contenant que cela le signale plutôt que de se charger vide.
• Le VHDL open source n'avait déjà besoin de rien ici : le backend GCC de GHDL instrumente avec -Wc,-ftest-coverage -Wc,-fprofile-arcs, et le résultat passe par gcov, gcovr ou lcov. Cette version est pour les simulateurs commerciaux.

Ajouté

• EMMA XML. Delphi n'avait aucun point d'entrée du tout — pas de lcov, pas de Cobertura — et DelphiCodeCoverage écrit exactement ce schéma avec -xml. C'est aussi ce qu'une bonne partie de l'outillage Java plus ancien produit encore, si bien qu'un seul analyseur ouvre un langage et évacue un héritage en même temps.
• Ajoutez -xmllines et le rapport gagne de vrais comptes de hits ligne par ligne, donc les gouttières fonctionnent ; sans cela il n'y a qu'un pourcentage cumulé, qui obtient un résumé de fichier et aucune gouttière plutôt qu'une supposition. Un nom de paquet à points ne devient un répertoire que lorsque le fichier est une source de la famille Java ; dans un rapport Delphi, ce même champ est un nom d'unité, et le préfixer inventerait un dossier que personne n'a sur disque.

Ajouté

• Exports de couverture TRACE32. COVerage.EXPORT.ListModule écrit ce qu'un débogueur a mesuré à partir d'une trace sur cible — pas une source instrumentée, mais le flux d'instructions réellement exécuté par le processeur, sur la cible réelle, sans aucun effet de sonde sur le timing. Un export porte une seule métrique à la fois : stmt devient couverture de lignes ; dec/cond deviennent couverture de branches ; mcdc devient MC/DC. Chargez deux exports d'une même exécution et ils fusionnent par nom de module.
• Les exports portant une couverture func, call ou object étaient refusés nommément plutôt que chargés vides, en indiquant quelle métrique le fichier contient — les trois ont désormais un foyer, respectivement en 0.2025.37, 0.2025.38 et 0.2025.39.

Ajouté

• Listings de profil d'exécution Testwell CTC++. ctcpost transforme MON.sym et MON.dat en un listing texte à largeur fixe — l'outil qui se trouve face à Bullseye dans les évaluations embarquées et de sécurité européennes, et celui qui mesure la couverture multiconditionnelle. Lu par position de colonne plutôt qu'en découpant sur les espaces, car une description peut elle-même commencer par un chiffre.
• La multiconditionnalité n'est pas le MC/DC, et n'est pas rapportée comme du MC/DC. CTC++ compte des combinaisons de conditions ; le MC/DC demande si chaque condition a été montrée comme influençant indépendamment le résultat. Placer ces chiffres derrière la porte MC/DC donnerait à un auditeur un nombre sous un nom qu'il ne signifie pas, donc ici ce sont de la couverture de branches, ce qu'ils sont réellement.

Ajouté

• VectorCAST XML. VectorCAST écrit un rapport Cobertura jusqu'au doctype, puis ajoute des attributs pour ce que Cobertura classique ne peut pas dire. Cela signifiait que ces fichiers se chargeaient déjà ici et paraissaient complets — avec mcdcpair-coverage discrètement écarté à l'entrée, précisément pour le public qui avait acheté un outil spécifiquement pour le produire. Ces comptages de paires survivent désormais. Ils alimentent la porte MC/DC, le pourcentage et le score composite.
• La couverture des appels de fonction n'est délibérément pas approximée. La replier dans la couverture des branches gonflerait un nombre qui finit dans un audit ; elle attend que le modèle ait un nom pour elle, ce qui arrive en 0.2025.38.

Modifié

• Le lecteur Cobertura porte désormais un dialecte : <coverage line-rate=…> est une famille, pas un seul format, et le dialecte lu voyage avec l'analyse au lieu d'être deviné par élément.

Ajouté

• GNATcoverage XML — Ada, enfin. Les équipes avioniques DO-178C et ferroviaires EN 50128 sont précisément le public pour lequel le score pondéré sûreté et la prise en charge MC/DC ont été conçus, et jusqu’ici elles ne pouvaient rien charger ici, sauf si leur gnatcov était assez récent pour produire aussi du Cobertura — qui jette tout ce qui se trouve sous la ligne. gnatcov coverage --annotate=xml écrit un répertoire et non un fichier : chargez les fichiers *.xml par source — ouvrir index.xml vous dit où se trouve réellement la couverture au lieu d’échouer obscurément. Une ligne partiellement couverte reste une ligne couverte avec une décision non couverte : le manque apparaît dans la couverture de branches et MC/DC, là où il se situe. Les zones d’exemption deviennent des lignes exclues, une obligation indéterminée compte comme non couverte plutôt que couverte, et avec --level=stmt+mcdc le MC/DC est compté par condition et alimente le seuil et le score composite.
• BullseyeCoverage et Visual Studio .coveragexml. Bullseye est l’outil C/C++ commercial que possèdent réellement les équipes embarqué et sûreté ; exécutez son propre covxml et chargez le résultat. Sa mesure phare est la couverture condition/décision et non la couverture de lignes, et les deux restent distinctes ici — de plus, une sonde à issue unique est notée sur un et non sur deux, afin qu’un switch entièrement testé ne soit pas donné pour à moitié couvert. Le .coveragexml de Visual Studio complète .NET pour les équipes sur MSTest et vstest plutôt que Coverlet : convertissez d’abord le .coverage binaire avec dotnet-coverage convert. Les lignes partiellement couvertes survivent au trajet dans les deux cas.
• Couverture générique SonarQube — et une réponse franche sur Xcode. Quatre attributs sur deux éléments, et cela compte parce que presque tout outil incapable de produire l’un des autres formats sait produire celui-ci : un projet dont l’outil de couverture est inconnu de cette extension a désormais une voie d’entrée. C’est aussi ce qu’écrit xcresultparser, et c’est ainsi que les projets Swift et Objective-C arrivent ici : .xcresult n’a pas de parseur, et la documentation dit maintenant pourquoi au lieu de vous laisser deviner — xccov rapporte des pourcentages, pas des données par ligne, et l’archive par ligne ne se lit qu’un fichier à la fois, dans un document qui ne nomme jamais le fichier qu’il décrit.
• Les tracefiles gzip se chargent tels quels. gcov --json-format écrit .gcov.json.gz par défaut : le format annoncé par la documentation était donc celui que la plupart des gens ne pouvaient pas charger. La détection se fait sur les octets magiques du fichier plutôt que sur son nom, de sorte qu’un rapport compressé ayant perdu son .gz fonctionne encore — et tout format pris en charge peut désormais arriver compressé, pas seulement celui de gcov.
• Swift et Objective-C, depuis le rapport propre à Xcode. xcrun xccov view --report --json est le seul document de couverture qu'une build iOS ou macOS produit sans outillage supplémentaire. Vous obtenez les pourcentages par fichier, les compteurs d'exécution par fonction et CodeLens. Il ne contient aucune donnée par ligne, et Studio n'en invente pas : les marges restent donc vides pour ce format — une marge inventée est indiscernable d'une marge mesurée. Pour une couverture Swift ligne à ligne, utilisez llvm-cov export -format=lcov ou slather, qui fonctionnaient déjà.
• Coveralls JSON — écrit par les reporters d'Elixir, Ruby, Python, Rust, Go et JavaScript. Par ligne, donc les marges fonctionnent.
• Jours actifs, blocages de seuil et la licence à laquelle un récapitulatif se rattache — trois ajouts au résumé d'utilisation mensuel, pour les installations ayant activé la télémétrie.

Supprimé

• Le nom de l'ordinateur n'est plus envoyé. hostname figurait dans la base de télémétrie depuis le début — hors de tout garde-fou, envoyé par quiconque avait la télémétrie activée. Un nom d'ordinateur est très souvent le nom d'une personne, un numéro de bureau ou le projet d'un client, et il ne répondait à aucune question sur l'usage à laquelle le système d'exploitation ne répondait pas mieux. Une installation est désormais identifiée par son seul identifiant d'installation aléatoire. Dès lors, rien qui vous nomme, vous ou votre machine, ne quitte celle-ci : ni le nom de l'ordinateur, ni le nom d'utilisateur du système, ni le répertoire personnel, ni les interfaces réseau, ni vos chemins de fichiers, ni le nom du dossier de votre projet, ni un libellé de compte connecté. Restent le système d'exploitation, sa version et son architecture — quel type de machine, pas laquelle.
• La télémétrie est désormais supprimée sous 90 jours au plus tard, là où la politique se contentait de dire qu'elle était « conservée tant qu'elle est utile », ce qui n'est pas un délai.

Modifié

• Une licence payante recharge désormais la couverture d'elle-même. Surveiller un fichier de couverture a toujours voulu dire se voir demander « nouvelle couverture détectée, la charger ? » après chaque build, sur toutes les éditions — une question à une seule réponse sensée, posée plusieurs fois par heure. Cette invite est maintenant le comportement de l'édition Community gratuite ; une licence payante charge, simplement. Community garde la surveillance, la détection et l'invite qu'elle a toujours eues.
• Un fichier incohérent est nommé, avec la vérification qui l'a prouvé, sur une licence payante. La détection n'est pas restreinte et ne le sera pas : dire à quelqu'un que sa couverture ne décrit plus son fichier n'est pas une chose à lui vendre. Community obtient toujours le constat, et la ligne reste grisée. Une licence payante ajoute le pointeur — la marque, le badge dans l'Explorateur, et la ligne, la fonction ou la somme de contrôle derrière.
• La télémétrie envoie moins, et dit à qui elle appartient. Le récapitulatif mensuel ne contient plus de chemins de fichiers, ni le nom du dossier de votre projet, ni d'étiquette de compte connecté. L'échange fonctionnalités-contre-télémétrie demande désormais une adresse e-mail, afin que la personne qui a accepté puisse savoir ce que son installation envoie et le faire supprimer sur demande.
• Trois descriptions de paramètres corrigées. watch.enabled, staleWarning.enabled et telemetry.enabled s'étaient chacune écartées de ce que fait le code — telemetry.enabled surtout : elle décrivait un envoi bien plus large que la réalité.

Corrigé

• Le sélecteur de fichiers ne masque plus les formats qu’il lit. Pick Coverage File filtrait sur info, json et xml : le coverage.out de Go et le .gcov.json.gz de gcov — deux formats que cette extension lit — étaient grisés dans la boîte de dialogue même qui vous demande d’en choisir un.
• Une installation Community ordinaire n'envoie plus une page de son code source. La vérification qui encadrait l'échantillon de source annoté traitait toute installation Community comme ayant accepté l'échange de télémétrie, et pas seulement celles qui l'avaient fait.
• Un avertissement par chargement au lieu de deux — un fichier qui ne correspond plus à sa couverture a presque toujours été modifié depuis l'exécution, et les deux étaient signalés séparément.
• Une désinstallation ne signale plus le nom d'utilisateur système ni le répertoire personnel de quelqu'un dont la licence l'interdit.

Ajouté

• Les profils de couverture Go. go test -coverprofile est la seule sortie de couverture que produit la chaîne d'outils standard de Go — il n'y a pas de lcov de repli comme pour Rust, Dart et Elixir — de sorte qu'un projet Go n'avait rien que cette extension puisse lire. Un profil enregistre des blocs et non des lignes, et chaque ligne couverte par un bloc reçoit son compteur, accolade fermante comprise, exactement comme go tool cover -html les met en évidence. coverage.out rejoint les noms recherchés par défaut : un projet Go sans configuration trouve son profil comme un projet C trouve lcov.info.
• Clover XML et OpenCover XML. Clover est ce que les projets PHP possèdent réellement : php-code-coverage peut émettre du Cobertura, mais Clover est son format par défaut et celui que configure presque chaque phpunit.xml — la couverture PHP était donc illisible ici pendant qu'un analyseur Cobertura attendait une sortie que presque personne ne génère. Le rapporteur clover d'Istanbul écrit le même document : un projet Jest ainsi configuré est couvert lui aussi. OpenCover est l'équivalent .NET : C# et VB.NET arrivaient déjà en Cobertura, qui aplatit une décision en la chaîne condition-coverage="50% (1/2)", si bien que la branche réellement empruntée avait disparu avant qu'un analyseur ne la voie. OpenCover conserve un compteur par branche — la différence entre savoir que la moitié d'un branchement est couverte et savoir laquelle.
• Le JSON de coverage.py et celui de gcov/gcovr. Les exports Cobertura et lcov de coverage.py doivent déclarer une ligne # pragma: no cover couverte ou manquante, faute de mot pour « délibérément exclue » — mot que cette extension possède, le même indicateur que posent ses marqueurs LCOV_EXCL. Les pragmas d'un projet Python signifient donc ici ce qu'ils signifient dans le rapport de coverage.py lui-même. La couverture GCC, de son côté, n'arrivait qu'après un détour par lcov ou gcovr -x : un second outil pour convertir des données que GCC avait déjà produites. gcov --json-format --stdout et gcovr --json produisent des documents quasi identiques, et un seul analyseur lit désormais les deux.

Corrigé

• Les commentaires sont lus dans la langue du fichier. L'analyseur de lignes non exécutables avait été écrit pour C et appliqué à tous les fichiers, ce qui était correct tant que chaque format lu par cette extension décrivait un langage de la famille C. Ce n'est plus le cas : un analyseur C rencontrant # don't voit l'apostrophe ouvrir une chaîne, ne la voit jamais se fermer, et compte la ligne de commentaire comme du code — un chiffre discrètement un peu faux, sans rien pour le signaler. C'est désormais # pour Python, Ruby, shell, Perl, R, Elixir et Julia ; les trois formes pour PHP, qui les accepte toutes ; et // avec /* */ partout ailleurs, ce qui reste la valeur par défaut pour une extension inconnue — #define est du code, et l'exclure serait faux dans l'autre sens.

Ajouté

• Chaque paramètre fuciniCoverage.* a désormais sa place dans ce panneau, pas seulement les treize paramètres de conformité. Les cinquante-cinq sont regroupés dans les mêmes sections, dans le même ordre, que la référence des paramètres publiée : la page depuis laquelle vous configurez et celle que vous lisez s'accordent donc sur l'endroit où vit un paramètre. Un champ de recherche filtre par nom, clé ou description ; une liste de liens permet de passer d'une section à l'autre. Le formulaire est dérivé à l'exécution du manifeste livré avec l'extension — types, valeurs par défaut, bornes, énumérations et chaque mot de texte — de sorte que rien n'est écrit deux fois et que le panneau ne peut pas diverger de l'extension qu'il modifie.
• Les descriptions suivent la langue que vous avez fixée. VS Code résout la localisation d'un manifeste à partir de la langue d'affichage de l'éditeur au chargement de l'extension, sans aucun moyen de la remplacer extension par extension — régler fuciniCoverage.language sur l'allemand dans un éditeur en anglais traduisait donc tout sauf les paramètres. Comme le panneau lit et résout ces fichiers lui-même, il est le seul endroit capable d'honorer ce choix.
• Les contrôles qu'un schéma JSON ne peut pas demander. Rien dans un schéma de paramètres n'indique qu'une chaîne est un chemin : l'interface native ne peut donc pas proposer de sélecteur. Les trois paramètres qui contiennent un répertoire disposent maintenant d'un bouton Parcourir…. coverageFile.paths et pathRemap obtiennent de véritables éditeurs de liste au lieu d'une zone JSON brute, et chaque couleur colorScale un échantillon à côté de sa valeur hexadécimale.

Modifié

• L'enregistrement écrit ce que vous avez modifié, et rien d'autre. Avec treize paramètres, le fait qu'Enregistrer les écrive tous les treize importait peu ; avec cinquante-cinq, cela reviendrait à imprimer tout l'espace de noms dans un settings.json qui comptait deux lignes. Seuls les paramètres dont la valeur a réellement changé sont écrits, et une valeur égale à la valeur par défaut supprime la surcharge au lieu de répéter ce que l'extension fournit déjà.
• Votre clé de licence va toujours dans vos paramètres utilisateur, et la ligne le dit. license.key est déclarée au niveau de l'application, ce qui signifie que VS Code ne la lit que là — l'écrire dans un espace de travail est un enregistrement qui semble fonctionner et ne change rien. Réinitialiser efface désormais les cinquante-cinq clés de la portée choisie au lieu de treize, et demande donc confirmation. Et une modification faite hors du panneau ne vous coûte plus votre place : la page compare avant de se redessiner, si bien qu'Enregistrer ne fait plus remonter cinquante-cinq lignes en haut.

Ajouté

• Le mode de conformité, les sept portes de seuil et les six poids du score composite ont désormais un seul éditeur. Ce sont treize lignes sans rapport dans l'interface des paramètres et une seule décision en pratique : un seuil reste inerte tant que le mode en vigueur ne le consulte pas, et un poids reste inerte tant que ce n'est pas la porte pondérée qui décide. Fucini Coverage: Configure Coverage Compliance & Thresholds..., sur le bouton en forme d'engrenage dans la barre de titre de la vue Coverage, réunit les trois, explique chaque mode là où le mode se choisit, et nomme les façons de configurer une porte pour qu'elle ne contrôle plus rien — un mode strict sans aucun seuil par métrique, un mode pondéré dont le seuil vaut 0, des poids tous à 0 — sous forme d'avertissements, pendant que vous les regardez.
• Il prévisualise le verdict et écrit via VS Code. Le CONFORME / NON CONFORME que produirait le formulaire non enregistré face à l'exécution chargée est calculé par le moteur de conformité de l'extension lui-même, et non par une seconde copie des règles : un aperçu capable de contredire la porte est pire que pas d'aperçu du tout. Les modifications passent par l'API de configuration ordinaire vers settings.json — utilisateur ou espace de travail, à votre choix —, de sorte que VS Code met en forme le fichier et conserve ses commentaires ; une modification faite à la main ou dans une autre fenêtre revient dans le formulaire ouvert, qu'une exécution soit chargée ou non. Aucune licence n'est requise : Community reçoit le même éditeur que Pro.

Corrigé

• Le bouton de la notification de mise à jour affichait Download && Install. L'esperluette doublée est l'échappement des mnémoniques, correct dans les titres de package.json et sur les boîtes de dialogue modales — mais les boutons d'action d'une notification prennent leur libellé tel quel, en texte brut, si bien que les deux caractères étaient affichés exactement comme écrits, dans les 17 langues, pour toute personne à qui une mise à jour était proposée.

Modifié

• La télémétrie est désactivée par défaut. Elle était livrée activée, au motif que la période d'évaluation avait besoin de ces données. Ce motif a cessé de valoir dès lors que le niveau Community a fait de l'activation de la télémétrie ce qui débloque gratuitement toutes les fonctionnalités Pro : un échange n'a de sens que si la personne le consent, et un échange que personne n'a choisi n'en est pas un. Rien n'est envoyé tant que vous ne l'activez pas, et Community continue de toute façon de fonctionner avec son ensemble de fonctionnalités standard.
• Le paramètre de télémétrie dit à quoi il sert et renvoie pour le reste. Sa description énumérait auparavant chaque champ transporté par un ping, ce qui faisait deux copies de cette liste — une dans le paramètre, une dans la politique de confidentialité — censées rester identiques à jamais, ce qui n'était plus le cas. Elle dit désormais ce que l'activation vous apporte et renvoie à la politique de confidentialité pour la liste des champs : une seule liste à tenir à jour au lieu de deux.
• Installer cette version rouvre votre fenêtre d'évaluation, une fois. Quiconque avait déjà épuisé son essai reçoit 14 nouveaux jours, parce que cette version change les conditions dans lesquelles l'évaluation avait eu lieu : un essai passé avec la télémétrie activée par défaut n'était pas un essai du produit désormais proposé. C'est délibérément lié à un jeton à usage unique plutôt qu'à la version — réinitialiser à chaque version reviendrait à ce que l'essai ne se termine jamais pour qui se tient à jour, ce qui n'est pas un essai mais une licence sans prix assortie d'étapes supplémentaires. Le jeton est consommé à la première activation et les règles ordinaires reprennent. Une licence payante n'est pas touchée, la vérification de clé retournant avant que l'essai ne soit consulté, et Community n'est pas concerné puisque cette édition n'a pas d'essai à rouvrir.
• Une clé de licence ne coûte plus un questionnaire. Les invites d'activation, le paramètre de clé de licence et la boîte de dialogue de fin d'essai présentaient tous une clé comme quelque chose d'émis en échange de réponses à des questions. Ce n'est pas le cas : la clé est émise automatiquement sur demande, et le questionnaire de retour est facultatif et entièrement distinct.

Corrigé

• Trois endroits promettaient encore un essai « jusqu'au 2026-12-31 ». Une telle date n'a jamais existé dans le produit — l'essai dure 14 jours, décomptés par installation à partir de la première utilisation. Deux versions précédentes avaient rattrapé cette affirmation dans les descriptions de paramètres et dans le README ; elle a survécu dans l'encadré d'évaluation de cette page, dans le Guide de l'utilisateur et dans le README de l'outillage de licence. Le Guide de l'utilisateur était le pire des trois : il indiquait que la fenêtre s'appliquait « pour chaque installation, dans le monde entier, en même temps (et non un décompte par installation) », soit exactement l'inverse, et affirmait que le rendu de couverture est suspendu à la fin de l'essai alors que l'extension revient en réalité au niveau gratuit Community.
• Les e-mails de notification de télémétrie partaient du mauvais domaine. L'en-tête From: était une boîte sur fucini.consulting alors que le serveur qui les envoie est fucini.software — précisément l'alignement contre lequel le commentaire du paramètre met en garde, et un moyen sûr de voir le courrier filtré comme spam ou rejeté d'emblée.

Modifié

• Un fichier que le rapport nomme mais qui n'est pas sur le disque s'affiche là où il doit être — grisé, et il explique pourquoi. 0.2025.25 a cessé d'inventer des emplacements pour ces fichiers, ce qui était juste, mais leur laissait un chemin relatif qui n'est pas un emplacement du tout — l'arbre continuait donc à faire un projet du premier segment, et les trois sources supprimées d'un sous-module se retrouvaient dans un app fantôme à côté du sous-module d'où elles venaient. L'incohérence était visible, c'était le but, mais au mauvais endroit et sans rien dire de ce qui n'allait pas.
• Il apparaît désormais dans le projet où il a été mesuré, dans le dossier que le rapport lui donne — dessiné dans le gris moyen du thème et en italique plutôt que dans la couleur de premier plan habituelle. Au survol, il donne le chemin qu'il aurait eu et explique qu'il n'y a rien — très probablement renommé ou supprimé après la génération du rapport — et que ses chiffres restent comptés. Rien n'est retiré et aucun total ne bouge : la ligne est ce que le rapport dit de lui-même, et le grisé est ce qui l'empêche de ressembler à une ligne qui s'ouvre.
• La supposition reste dans la vue. Le chemin enregistré du fichier est toujours exactement celui du rapport, car tout le reste s'y réfère — l'enrichissement du rapport externe s'y compare, la télémétrie le relativise, la vue annotée l'ouvre — et leur donner un emplacement présumé échangerait du connu contre de l'inventé. Seul l'arbre réunit les deux, et seulement pour un chemin qui ne nomme aucun emplacement propre : un chemin absolu qui n'existe simplement pas conserve ce que disait le rapport et est grisé là où il est.

Corrigé

• La couverture d'un sous-module atterrit là où le sous-module se trouve vraiment, et ses lignes s'ouvrent. Un sous-module git construit son propre rapport à côté de son propre arbre, et gcovr y écrit <source>.</source> — « le répertoire où se trouve ce fichier » — avec des noms comme app/Application.cpp en dessous. Rien n'ancrait ce . : les chemins étaient résolus une seule fois, après la fusion, quand l'exécution ne savait plus de quelle entrée venait chaque fichier — la seule base restante était la racine de l'espace de travail. Essayer <workspace>/app/Application.cpp ne trouvait rien, chaque chemin restait relatif, et la vue Couverture les dessinait comme un projet nommé app — d'après le premier segment d'un chemin qui n'a jamais été un emplacement — dont chaque ligne copiait et ouvrait là où aucun fichier ne se trouvait.
• Les chemins sont désormais résolus par fichier de trace, avant la fusion. Un sourceRoot relatif est ancré au répertoire où se trouve son fichier de trace : . à côté du coverage.xml d'un sous-module désigne donc ce sous-module. Si cela ne trouve pas les sources, la recherche remonte vers le haut depuis le fichier de trace — la disposition CMake habituelle écrit la couverture plusieurs niveaux plus bas dans build/, et laquelle des deux formes un projet utilise n'est écrite nulle part dans le rapport : c'est donc le système de fichiers qui répond, pas la configuration. La remontée s'arrête à la racine de l'espace de travail : aller au-delà laisserait un simple src/main.c se résoudre dans un dépôt voisin de même disposition — une mauvaise réponse qui ressemble à une bonne. Un chemin déjà absolu et présent reste tel quel : les exécutions lcov ordinaires ne changent pas.
• Un sous-module reste son propre projet dans la vue Couverture. Les fichiers qui se résolvent désormais dans l'espace de travail auraient sinon été fondus dans son arbre — les dossiers du sous-module entrelacés avec ceux du parent, et ses chiffres ajoutés au total du parent comme si une seule base de code avait été mesurée deux fois. Chaque fichier retient la racine depuis laquelle il a été mesuré, et la vue regroupe là-dessus : un sous-module garde donc son propre titre et ses propres totaux, même s'il se trouve dans le dossier ouvert. Une exécution aux chemins déjà absolus n'a pas de telle racine et se regroupe comme avant.
• Un fichier que le rapport nomme mais qui a disparu est toujours signalé manquant. On ne lui donne pas un chemin plausible où il n'est pas : un rapport nommant des fichiers supprimés depuis est un rapport périmé, et les dessiner à des emplacements inventés le masquerait. Chacun est nommé dans le canal de sortie sous FUCINI_REMAP_001, avec le chemin qu'il aurait eu.

Modifié

• Un poste qui disparaît dit désormais pourquoi. Chaque révocation affichait la même ligne — votre poste dans ce forfait n'est plus actif — ce qui se lit comme un reproche adressé à la mauvaise personne. Un abonnement d'équipe réduit en dessous du nombre de postes utilisés libère maintenant le surplus après un délai de grâce, et celui qui perd un poste n'a rien fait d'autre que d'être celui qui ne s'en était pas servi depuis le plus longtemps. Là où le serveur de licences a quelque chose d'utile à dire, l'extension le dit : un poste libéré pour tenir dans un abonnement réduit l'explique exactement et renvoie vers la personne qui gère l'abonnement, avec Demander une nouvelle clé toujours proposé — car le retour est réel : le pool a de la place dès que cette personne en libère une.
• Un abonnement terminé ne propose aucun bouton. Aucune nouvelle clé ne peut être émise depuis un abonnement expiré ; la seule action de cette notification ne pouvait donc qu'échouer — ce qui se lit comme une extension cassée plutôt que comme un abonnement terminé. Elle dit désormais ce qui s'est passé et s'arrête là. Toute raison que cette version ne reconnaît pas conserve la formulation générale : le serveur de licences est déployé en continu, pas une extension installée ; rencontrer une raison inconnue est donc le cas ordinaire et non le cas limite — jamais d'identifiant brut affiché, jamais de silence. Les deux nouveaux messages sont traduits dans les dix-sept langues.

Ajouté

• L'exécution peut enfin sortir, en six formats de plus. Jusqu'ici il n'y avait que deux sorties : Fucini JSON, que rien d'autre que l'extension ne lit, et un rapport HTML, que rien ne lit mécaniquement. Export Coverage Report... ouvre un sélecteur de format et écrit l'exécution active en CSV par fichier (couvert/total/pourcentage pour les lignes, branches, fonctions, MC/DC, régions et instanciations, les moins couverts d'abord, avec une ligne TOTAL), en CSV par fonction (nombre d'exécutions, si elle a tourné, branches non couvertes à l'intérieur, paires MC/DC), en résumé Markdown à coller dans une pull request, en fichier de trace LCOV, en XML Cobertura, en SARIF, ou en badge SVG autonome pour un README. On le trouve dans la palette de commandes, dans la barre de titre de la vue Covered Files à côté de Generate Full HTML Report, et dans le menu rapide de la barre d'état dès que quickActions.exportReport est activé.
• C'est désormais un convertisseur, pas seulement une visionneuse. L'extension lit déjà lcov, llvm-cov JSON, Cobertura, JaCoCo, Istanbul/nyc et SimpleCov ; avec les écrivains LCOV et Cobertura, elle sait aussi faire le chemin inverse. Chargez un rapport JaCoCo, ou plusieurs rapports fusionnés en une seule exécution, et produisez l'unique fichier de trace que genhtml, Codecov, Coveralls et SonarQube acceptent tous — ou le XML que Jenkins, GitLab et Azure DevOps ingèrent nativement. Les deux repassent par les propres analyseurs de l'extension, et les plages de lignes sont développées ligne par ligne pour que les LF/LH écrits correspondent au pourcentage affiché au lieu de l'approcher.
• Chaque écrivain dit ce qu'il abandonne. Tous sauf les CSV sont à perte, et silencieusement : MC/DC, régions de code et instanciations C++ n'ont aucune représentation en LCOV, Cobertura ou SARIF, et Cobertura note combien de conditions d'une ligne étaient couvertes, pas laquelle. Fucini JSON et les deux CSV restent les formats qui portent tout ce qui a été mesuré. Dans les CSV, une métrique que l'exécution ne possède pas laisse ses cellules vides plutôt qu'à zéro — une cellule vide dit « cet outil n'a signalé aucune donnée de branche », un 0 dirait « aucune branche n'a été atteinte », et un tableur ne saura plus les distinguer ensuite. Tout ce qu'un tableur exécuterait sinon comme formule — un champ commençant par =, +, - ou @, c'est-à-dire tout chemin npm à portée — est mis entre guillemets et désamorcé avant écriture.
• SARIF annote la diff ; le badge ne demande rien au réseau. Les plages non couvertes sont signalées au niveau note, pas warning : le code non couvert renseigne sur la suite de tests, et l'analyse de code traite un avertissement comme quelque chose qui devrait bloquer — la barrière qui bloque reste Check Coverage Thresholds. Le badge est dessiné ici plutôt que récupéré sur shields.io : il fonctionne donc dans un dépôt isolé ou hébergé sur site, et prend sa couleur de la même colorScale que les marges et la barre d'état. Dans l'édition Community gratuite, le sélecteur s'ouvre et les deux CSV fonctionnent, plafonnés à 20 exports par jour comme Export Fucini JSON ; les formats d'échange sont payants, sur la ligne que cette édition a toujours tracée — lire ses propres chiffres est gratuit, alimenter une chaîne d'intégration continue ne l'est pas.

Corrigé

• Un fichier qui n’a rien à instrumenter n’est plus annoncé comme couvert à 100 %. Un en-tête de simples déclarations — des prototypes, une macro, des gardes d’inclusion — n’a aucun corps de fonction : le compilateur n’émet donc aucune donnée de couverture pour lui, et tout ce qui divise zéro par zéro répond 100 %. Il apparaissait en vert dans l’arbre, à côté de code réellement testé. Les deux lecteurs prennent désormais les totaux de l’outil lui-même comme le compte rendu du fichier sur lui-même — LF/FNF/BRF en lcov, le bloc summary dans le JSON llvm-cov — et un fichier dont tous les totaux valent zéro est écarté de l’exécution au lieu d’être noté. Les enregistrements ligne à ligne situés sous ces totaux sont délibérément ignorés : l’expansion d’une macro est rattachée à la ligne qui la définit alors que le compte appartient à la ligne qui l’utilise, dans un autre fichier, et cette ligne empruntée était la seule raison pour laquelle un tel en-tête semblait mesuré. Les totaux d’exécution la perdent aussi : le chiffre affiché est un peu plus bas et bien plus juste. Chaque chemin écarté est nommé dans le canal de sortie, et un rapport où tous les fichiers sont de simples déclarations les conserve tous.

Modifié

• Pick Coverage File s’ajoute à ce qui est déjà chargé au lieu de le remplacer. Une compilation qui écrit un rapport par module n’a aucun fichier unique à fixer, et choisir le rapport du deuxième module déchargeait silencieusement le premier. La boîte de dialogue accepte maintenant plusieurs fichiers à la fois, chaque choix s’ajoute à l’ensemble, et tout ce qui est choisi est fusionné en une seule exécution — dessinée dans le panneau sous le nom propre de chaque projet. La surveillance les suit tous, et un rapport régénéré ne fait plus disparaître les autres. Show Loaded Coverage Files se termine par Décharger les fichiers sélectionnés, qui revient à la recherche ordinaire.
• Le support dispose d’une adresse sur le domaine du produit : support@fucini.software. Lorsque l’activation ne peut aboutir seule, le panneau de licence et le message du code de demande donnaient une adresse fucini.consulting — un domaine différent de tous les autres liens de l’extension, et qui se lit comme une autre société. license@fucini.software ne change pas : c’est l’expéditeur des clés, pas une boîte où écrire.

Ajouté

• Chaque arborescence de la vue Coverage indique désormais à quel projet elle appartient. La 0.2025.19 donnait à une exécution fusionnée un bloc nommé par projet, mais une exécution ordinaire dessinait encore une arborescence nue — un espace de travail ramené à son propre dossier s'ouvrait donc sur src, sans rien au-dessus pour dire de quel src il s'agissait. Chaque arborescence porte maintenant sa racine : les dossiers menant au projet dans la couleur atténuée, le dossier propre du projet ensuite, en pleine couleur. Une arborescence ramenée au dossier de l'espace de travail dit toujours à quoi elle a été ramenée, et deux bases de code fusionnées en une seule exécution ne sont jamais lues comme une seule arborescence. C'est un en-tête et non une ligne — il n'y a rien à y déplier, et les dossiers en dessous se replient exactement comme avant. Dans un panneau étroit, les répertoires de tête se raccourcissent en premier, si bien que le dossier qui nomme réellement le projet disparaît en dernier, et le survol affiche le chemin entier.

Ajouté

• Les lignes de la vue Coverage ont le menu contextuel de l'Explorateur. Un clic droit sur un fichier ou un dossier ouvrait jusqu'ici le Couper/Copier/Coller de la webview — trois entrées sans rien sur quoi agir. Il ouvre désormais le vrai menu de VS Code : Ouvrir, Open to the Side, Ouvrir avec…, Reveal in Explorer View, Reveal in File Explorer, Open in Integrated Terminal, Rechercher dans le dossier… pour un dossier, ainsi que Copy Path / Copy Relative Path — avec, sous Windows, les variantes à barres obliques là où les deux formes diffèrent. Le bouton ⋯ et son menu sont inchangés et constituent la dernière entrée du nouveau menu.

Modifié

• Une métrique pour laquelle votre fichier de couverture n'a aucune donnée n'est plus jugée. Un seuil MC/DC sans MC/DC dans la compilation comptait comme un échec — un fichier à 100 % sur chaque métrique réellement mesurée se retrouvait sous une carte indiquant « 3 sur 5 atteints », face à une barre que rien dans ce fichier ne pouvait franchir. Les métriques sans données sont désormais ignorées partout où un verdict se forme : la barre d'état par fichier, la carte de l'exécution complète, le bandeau du code annoté et le rapport HTML. Check Coverage Thresholds nomme toujours explicitement une métrique manquante, et c'est là que cela a sa place.
• Les fichiers sans rien de mesurable ne figurent plus dans la vue Coverage. Un en-tête de déclarations, un fichier de simples réexports, un module de types seuls : aucun test que vous écrirez ne changera leur chiffre, et les ouvrir n'affiche aucune métrique. En 0.2025.19 ils portaient un tiret ; ils ne sont tout simplement plus listés, et les dossiers ainsi vidés disparaissent avec eux. Une exécution où rien n'est mesurable liste toujours tout.

Corrigé

• Une lettre de lecteur pouvait encore coiffer l'arborescence. Pour une couverture dont les chemins ne se trouvent pas sous le dossier de travail ouvert — un fichier fusionné venu d'un autre projet, ou une fenêtre sans dossier ouvert — l'arborescence commençait à W:, ou, sous Linux et macOS, par une ligne sans nom du tout : une ligne, un seul enfant, dépliable pour rien. La racine du système de fichiers n'est plus jamais dessinée, quels que soient les chemins, et chaque ligne conserve son vrai chemin absolu pour le menu et l'éditeur.

Ajouté

• Un menu de ligne sur chaque fichier et chaque dossier de la vue Coverage. Le bouton en bout de ligne copie ce chemin sous chacune des quatre formes qu'un éditeur, un shell ou une invite peut attendre — absolu ou relatif à l'espace de travail, avec les séparateurs du système ou avec des barres obliques — et propose Reveal in File Explorer et Open in Integrated Terminal, un fichier ouvrant le terminal dans son propre répertoire. Les entrées à barres obliques ne figurent que là où elles diffèrent de la forme native : sous Linux et macOS, le menu compte donc deux entrées de moins. Copier un chemin obligeait auparavant à retrouver le même fichier une seconde fois dans l'explorateur.
• Des boutons tout replier et tout déplier au-dessus de l'arborescence. Tout replier puis n'ouvrir que le dossier qui vous intéresse est le chemin le plus rapide dans une grande arborescence, et cela coûtait jusqu'ici un clic par dossier. Ce que vous repliez ainsi est mémorisé exactement comme un dossier fermé à la main : un rechargement ne l'annule pas.
• Une exécution fusionnée couvrant plusieurs projets dessine désormais chaque projet séparément, sous son propre nom. Fusionner un fichier de trace d'une seconde base de code accrochait ses dossiers à la même arborescence que ceux de l'espace de travail : src apparaissait deux fois sans explication, et les répertoires des deux projets s'entremêlaient par ordre alphabétique. Chaque projet reçoit maintenant son propre bloc nommé, séparé par un filet, celui de l'espace de travail en premier. Une exécution ne couvrant qu'un seul projet est inchangée et ne porte aucun titre — il n'y aurait rien pour l'en distinguer.

Corrigé

• Un fichier sans rien d'exécutable était signalé comme couvert à 0%. Un module qui ne contient que des réexports export *, ou uniquement des déclarations de types, se compile en quelque chose qu'aucun outil de couverture ne peut mesurer — le fichier de trace n'enregistre donc aucune instruction pour lui. La vue Coverage lui donnait 0% et le classait en rouge à côté de code réellement non testé, alors qu'il n'y a rien à tester ; l'explorateur, lui, affichait pour le même fichier un 100% vert, parce qu'un total vide se lit comme « tout de rien est couvert ». Aucun de ces deux chiffres n'était vrai et aucun n'est plus affiché : la ligne du panneau reçoit un tiret et un contour pointillé, avec une infobulle qui explique pourquoi, et la pastille de l'explorateur est omise. Un dossier ne contenant que de tels fichiers reste lui aussi sans score. Un fichier à 0% de quelque chose qui a bien été mesuré affiche toujours 0% — le tiret signifie « rien à mesurer », pas « mesuré et manqué ».
• Les lignes issues d'un projet fusionné pointaient au mauvais endroit. Leurs chemins étaient construits depuis la racine de l'espace de travail et non depuis la leur : pour un fichier hors de l'espace de travail, le menu de ligne copiait — et «Reveal in File Explorer» ouvrait — un chemin où le fichier ne s'est jamais trouvé. Elles portent désormais la racine dont elles proviennent réellement.

Modifié

• La vue Coverage ne dessine plus la racine de l'espace de travail. L'arborescence partait de la racine du système de fichiers et descendait par chaque dossier au-dessus du projet — le disque, puis le répertoire contenant vos projets, puis le projet lui-même — avant d'atteindre le premier dossier qui était vraiment le vôtre. Cela faisait plusieurs niveaux d'indentation, sur chaque ligne, répétant ce que le titre de la fenêtre disait déjà. Les chemins commencent désormais au dossier de l'espace de travail. C'est toujours le chemin absolu complet que le menu de ligne copie et que l'éditeur ouvre.

Corrigé

• Les dossiers repliés dans la vue Coverage se rouvraient à chaque rechargement. La surveillance est activée par défaut : une compilation qui régénère la couverture redessine donc le panneau — et comme chaque dossier était dessiné ouvert, un repli ne durait que jusqu'à la compilation suivante. Sur une grande arborescence, cela voulait dire refaire le même travail plusieurs fois par heure. Le panneau se souvient désormais des dossiers que vous avez fermés et les laisse fermés. Un répertoire qui apparaît pour la première fois dans une exécution ultérieure s'affiche toujours ouvert, comme n'importe quel autre : ce qui est mémorisé, c'est le geste délibéré de fermer un dossier, pas l'état par défaut.
• Désactiver la télémétrie n'arrêtait pas le signal de désinstallation. Ce signal est envoyé par un petit script autonome que VS Code exécute lors de la désinstallation. Il n'a pas accès à l'API de VS Code et ne peut pas lire vos paramètres ; la seule chose qui lui indique de ne rien envoyer est donc l'absence d'un fichier que l'extension écrit tant que la télémétrie est activée — et ce fichier n'était jamais supprimé quand vous désactiviez la télémétrie. Quiconque l'avait activée puis désactivée aurait quand même envoyé, à la désinstallation, son nom d'utilisateur du système, son nom d'hôte et son répertoire personnel. Le fichier est désormais supprimé dès que la télémétrie est désactivée.
• Un renouvellement Pro pouvait annoncer un succès pour une clé que vous veniez de remplacer. Le renouvellement silencieux lisait la clé configurée deux fois : une fois pour décider s'il fallait renouveler, puis une seconde fois pour décider s'il fallait afficher un message. Coller une nouvelle clé pendant un renouvellement en cours faisait que la seconde lecture voyait une autre clé, et le message « votre abonnement Pro a été renouvelé » décrivait celle qui venait d'être remplacée. La clé n'est désormais lue qu'une seule fois.

Modifié

• Chaque module de l'extension est désormais couvert par ses propres tests. Pour un outil dont tout le travail consiste à vous dire ce que vos tests atteignent réellement, cela méritait d'être fait sérieusement : 53 des 54 fichiers source sont à 100% en instructions, branches, fonctions et lignes, et le dernier — la couche de liaison avec VS Code — à 95% de ses fonctions. Les écrire a révélé les défauts ci-dessus, ainsi qu'une vingtaine de garde-fous qui ne pouvaient jamais s'exécuter : des solutions de repli placées derrière des vérifications qui les avaient déjà exclues, qui ressemblaient à des filets de sécurité sans rien rattraper. Ils ont été supprimés plutôt que masqués par un test incapable d'échouer.

Modifié

• Lʼenquête facultative attend désormais que vous ayez réellement utilisé lʼextension, et arrive à un meilleur moment. Elle comptait les jours calendaires depuis lʼinstallation, mesurant depuis combien de temps vous lʼaviez installée plutôt que si vous lʼaviez vue fonctionner — une installation restée intacte pendant un mois se voyait demander dʼévaluer un produit qui ne lui avait jamais rien montré. Il faut maintenant de vrais chargements de couverture en plus du temps écoulé, et elle nʼapparaît plus pendant le démarrage de lʼéditeur : elle attend quʼun chargement ait réussi. Une troisième et dernière invitation arrive après un an, car deux dans un même trimestre écartaient définitivement quiconque était simplement occupé à ce moment-là.
• La traduction néerlandaise nʼest plus formelle. Elle vous vouvoyait partout avec « u », ce qui sonne raide pour un outil de développement et ne correspondait à rien dʼautre dans la voix du produit. Tous les textes néerlandais utilisent désormais « je » — réécrits phrase par phrase, car le changement entraîne les formes verbales.

Modifié

• Le formulaire d’activation demandait un « company code » aux développeurs indépendants. Acheter Pro ou Pro Plus seul donne un code issu de votre propre abonnement : il n’y a pas d’entreprise derrière, et se voir demander la sienne laisse penser qu’on s’est trompé de formulaire. Ce champ s’appelle désormais Subscription code pour Pro et Pro Plus, et reste Company code pour Business et Enterprise, où une équipe en partage réellement un. Les indications en dessous étaient déjà propres à chaque offre ; seule l’étiquette était restée générique.

Corrigé

• Le rapport HTML généré jugeait votre code à 100 %, quels que soient les seuils définis. La colonne Statut testait chaque métrique face à un 100 caché : un projet fixant ses seuils à 80 et les respectant voyait une bannière verte COMPLIANT juste au-dessus d'une colonne de croix rouges, pour la même exécution, sur la même page. La légende des métriques faisait de même. Les deux utilisent désormais vos seuils, et là où aucun seuil ne s'applique, elles affichent un tiret discret plutôt qu'un verdict inventé.
• La bannière de conformité affirmait plus qu'elle n'avait vérifié. Elle indiquait toujours « tous les seuils configurés sont atteints », y compris dans le mode par défaut, qui ne teste que le score pondéré — une exécution pouvait donc affirmer que chaque seuil était atteint alors que l'un d'eux échouait visiblement dans le tableau en dessous. Chaque mode indique maintenant la règle réellement appliquée.
• Le README annonçait que l'extension « est gratuite jusqu'au 2026-12-31 ». Cette date n'existe pas dans le produit. Une version antérieure avait corrigé cette affirmation dans les descriptions de paramètres mais avait oublié le README — la première chose que l'on lit sur la Marketplace. Il décrit désormais la réalité : 14 jours d'essai à partir de la première utilisation, puis le niveau Community gratuit, sans date après laquelle quoi que ce soit s'arrête.

Modifié

• Les deux éditions ne se ressemblent plus à l'identique sur la Marketplace. Pro et Community sont construites à partir d'un même arbre de sources, et jusqu'ici cela incluait l'icône : les deux fiches étaient donc la même image avec une légende différente, côte à côte dans les mêmes résultats de recherche. Chaque édition a désormais la sienne : le même visuel avec un bandeau coloré en bas, turquoise pour Pro et ardoise pour Community. C'est le mot qui les distingue lorsque l'icône est affichée en grand ; dans une ligne de résultats, le mot est trop petit pour être lu, et c'est la couleur qui s'en charge.

Corrigé

• Ouvrir la vue annotée ne vous empêche plus de la rouvrir. Le panneau de source annotée est une webview et non un éditeur de texte : tant qu'il avait le focus, l'extension ne voyait aucun « fichier courant », et Open Annotated Source y répondait « ouvrez d'abord un fichier avec une couverture chargée », à quelqu'un qui regardait précisément la vue annotée d'un fichier couvert. La commande se rabat désormais sur le fichier derrière le panneau que vous avez sous les yeux. Ce même blocage escamotait aussi la re-vérification pour laquelle un second appel existe : lorsqu'un rapport HTML llvm-cov est configuré, c'est ce second appel qui bascule le panneau vers la page de ce rapport — si votre build de couverture se terminait après l'ouverture du panneau, il était donc impossible de la récupérer depuis le panneau lui-même.

Ajouté

• Un abonnement Pro payant se renouvelle désormais tout seul. Chaque clé d'activation ne dure que la période réellement payée. Les formules d'équipe récupèrent la période renouvelée à leur prochain contact, mais Pro individuel ne contacte jamais le serveur — il fonctionne entièrement hors ligne —, donc rien ne lui apportait ce renouvellement, et la clé d'un abonné mensuel aurait expiré environ chaque mois, aussi fidèlement qu'il paie. L'extension demande maintenant une nouvelle clé discrètement, uniquement dans les jours entourant sa propre expiration et seulement lorsqu'elle détient le code prouvant qu'un abonnement l'a payée. Être hors ligne pendant cette fenêtre ne coûte rien : la clé continue de fonctionner jusqu'à sa véritable expiration, et la tentative suivante la restaure.
• L'activation depuis l'e-mail d'achat tient en un clic. Le lien transmet directement votre formule et votre code à l'extension, au lieu d'ouvrir VS Code, chercher la commande et coller le code à la main. Une confirmation est toujours demandée avant d'utiliser un poste. Saisir le code soi-même fonctionne exactement comme avant — le lien est un raccourci, jamais le seul chemin — et il fonctionne aussi dans la version Community.

Corrigé

• La description d'un paramètre affirmait que l'extension est "gratuite jusqu'au 2026-12-31". Cette date n'existe nulle part dans le produit. En réalité, il s'agit d'un essai de 14 jours à compter de la première utilisation, après quoi l'extension revient au niveau gratuit Community. C'est ce qu'elle dit désormais, dans toutes les langues.
• Les paramètres de seuil ne citent plus la version qui a changé leurs valeurs par défaut — un numéro de version au milieu d'une phrase répond à une question que personne ne se pose en lisant la description d'un paramètre.
• Plusieurs descriptions traduites nommaient une commande qu'aucun VS Code traduit n'affiche. Elles désignaient la commande d'activation par son nom anglais, envoyant ceux qui ne travaillent pas en anglais chercher dans la palette une chaîne qui ne s'y trouve pas.

Corrigé

• Un projet sans décisions MC/DC pouvait afficher 0 % de couverture globale. Certains outils signalent une section MC/DC même lorsqu’il n’y a rien à y mesurer, ce qui était interprété comme « 0 % couvert » au lieu de « rien à couvrir ». Comme le score global tombe à zéro dès qu’une métrique vaut zéro, un projet entièrement couvert pouvait afficher 0 %. Une métrique sans rien à mesurer est désormais totalement exclue du score, et sa ligne disparaît au lieu de s’afficher comme « 0 / 0 conditions couvertes ».
• L’état de la licence est maintenant traduit dans les 17 langues. Il restait en anglais partout et, comme il s’insère dans des phrases déjà traduites, cela produisait une ligne à moitié traduite dans la barre d’état, dans les notifications et dans le panneau des fichiers couverts.
• La vue Source annotée et les infobulles de couverture sont également traduites — le tableau de détail de la conformité, les boutons de navigation et leurs infobulles, ainsi que le détail des branches et du MC/DC affiché au survol.

Modifié

• Un abonnement Pro payant peut désormais être activé avec son propre code. La liste des forfaits de la demande de clé comporte maintenant une entrée Pro, si bien que le code fourni avec un abonnement Pro a enfin un endroit où être saisi. Les clés Pro individuelles fonctionnent toujours entièrement hors ligne et ne contactent jamais le serveur après l’activation.
• L’icône de la barre d’activité est plus grande et plus lisible à côté des icônes intégrées.
• Passer à l’édition Community l’installe désormais depuis fucini.software. Auparavant, la Marketplace était utilisée, alors que l’édition Community n’y est pas publiée : le basculement pouvait donc vous laisser sans aucune extension installée.

Modifié

• Un abonnement expiré bascule désormais sur le niveau gratuit — lorsqu'une clé d'activation individuelle arrivait à expiration, l'extension vous demandait indéfiniment de la renouveler. Choisir de ne pas renouveler est une fin normale d'abonnement, pas une anomalie : l'extension bascule donc désormais sur le niveau Community gratuit et permanent. Les forfaits d'équipe ne sont délibérément pas concernés : une clé Pro Plus, Business ou Enterprise expirée continue d'être signalée comme expirée, car c'est alors à un administrateur de la renouveler, et faire basculer silencieusement toute l'entreprise sur le niveau gratuit masquerait ce fait.

Corrigé

• La désactivation de la télémétrie est désormais respectée dans tous les cas. Un chemin de code pouvait ignorer la vérification lorsque le mode de diagnostic détaillé interne de l'extension était activé. Ce mode est désactivé dans chaque build publié, de sorte qu'aucune version n'a jamais eu ce comportement, mais la vérification est maintenant inconditionnelle.
• Les paramètres s'appliquent immédiatement au lieu d'attendre un rechargement. Modifier le remappage des chemins, l'exclusion des commentaires, le filtrage par git-diff ou les totaux des fichiers exclus recharge désormais la couverture immédiatement — le remappage des chemins tout particulièrement, puisque c'est justement le paramètre auquel on a recours parce que les chemins ne correspondent pas.
• « Unlock Full Features » et « Switch to Community » pouvaient s'arrêter à mi-chemin sans le signaler. Les deux vont désormais jusqu'au bout.
• Votre clé d'activation reste liée à la même identité de machine. Sur certaines configurations, cette identité pouvait auparavant être régénérée d'une session à l'autre, ce qui invalidait une clé déjà délivrée.

Ajouté

• Traductions complètes dans les 17 langues livrées — une centaine des textes d'interface les plus récents, dont les boîtes de dialogue d'activation et de licence, le questionnaire de retour facultatif, le parcours de déblocage Community et les notifications de mise à jour automatique, revenaient encore à l'anglais dans chaque ensemble non anglophone. Les 17 langues couvrent désormais l'intégralité de l'interface d'exécution de l'extension.

Modifié

• Passage d'entretien sur les commentaires du code source, la documentation des scripts de build et la liste des fichiers d'empaquetage. L'ensemble des fichiers livrés dans l'extension est inchangé ; aucun changement fonctionnel ni comportemental.

Corrigé

• Installer à la fois les éditions Pro et Community pouvait faire planter l'une d'elles au démarrage — elles enregistrent les mêmes commandes et la même vue des fichiers de couverture. Le cas est désormais détecté en amont : si l'autre édition est également installée, l'activation s'arrête proprement avec un message vous invitant à en désinstaller une, au lieu d'un échec d'activation inexpliqué.

Version de maintenance ; aucun changement fonctionnel.

Un niveau gratuit permanent, des forfaits d'équipe qui partagent un pool de postes, et une édition Community distincte de l'extension.

Ajouté

• Un niveau Community permanent et gratuit — au lieu d'un arrêt net une fois l'essai de 14 jours terminé, l'extension bascule désormais sur Community : toutes les fonctionnalités sauf MC/DC, un aperçu mensuel limité du Full HTML Report et des vues Annotated Source persistantes, des plafonds quotidiens généreux sur une poignée d'actions automatisables, et tout le reste sans limite.
• Débloquez toutes les fonctionnalités gratuitement — une nouvelle commande « Unlock Full Features » échange une télémétrie d'usage détaillée contre un octroi complet et sans restriction, réversible à tout moment. Un questionnaire de retour facultatif dans l'application donne à la place une clé de 30 jours avec toutes les fonctionnalités, sans aucune contrepartie.
• Forfaits d'équipe : Pro Plus, Business et Enterprise — ceux-ci partagent un pool de postes (un code d'entreprise plus un nombre de postes) au lieu d'une clé par machine, avec une vérification en arrière-plan qui maintient à jour l'octroi d'un poste et signale automatiquement un poste révoqué ou réduit.
• Fucini Coverage Studio Community — une fiche distincte et dédiée, construite à partir du même code source, dans laquelle le code d'essai, d'activation et de forfait d'équipe des niveaux payants est réellement absent plutôt que simplement masqué. Voir la page de téléchargement.

Modifié

• La génération du Full HTML Report et les vues Annotated Source persistantes (simple et côte à côte) sont désormais des fonctionnalités des niveaux payants dans la base Community — seule la vue à bascule sur place demeure, plafonnée mensuellement comme auparavant. Le déblocage donne toujours accès à l'ensemble.
• Un avertissement de limite d'usage au niveau Community propose désormais les deux voies possibles dans une seule invite : consulter les forfaits payants, ou débloquer via la télémétrie.

Corrigé

• La télémétrie détaillée et potentiellement identifiante (nom d'utilisateur du système, répertoire personnel, caractéristiques CPU/RAM, interfaces réseau, et le contenu intégral du rapport et du code source) ne peut désormais être envoyée que par Community ou par un octroi gratuit conditionné à la télémétrie — jamais par une licence payante Pro/Pro Plus/Business/Enterprise, quels que soient les paramètres de télémétrie locaux.
• Une installation qui exécutait déjà une version antérieure ne se voit plus attribuer une nouvelle période d'essai du simple fait de sa mise à jour — elle arrive désormais correctement au niveau Community si son ancien essai était déjà épuisé.
• La notification de mise à jour, la progression du téléchargement et les messages d'erreur affichent désormais la version simple Major.Year.Minor (identique à ce qu'affiche la vue Extensions de VS Code) au lieu de divulguer le numéro de build interne, par exemple 0.2024.6 au lieu de 0.2024.6.2.

Les clés d'activation peuvent désormais plafonner chaque fonctionnalité séparément, et les administrateurs de licences peuvent délivrer à la main une clé finement réglée depuis le tableau de bord.

Ajouté

• Plafonds d'usage par fonctionnalité — les clés d'activation peuvent désormais plafonner chaque fonctionnalité ou action indépendamment (par exemple, les exports de rapport HTML à 1 par mois) au lieu d'une limite unique et partagée sur les chargements de couverture. Les clés existantes continuent de fonctionner sans changement.
• Délivrance manuelle de clés — les administrateurs de licences peuvent désormais délivrer à la main une clé pour un code de demande reçu en dehors du questionnaire intégré à l'éditeur, en choisissant exactement les fonctionnalités à accorder, une date d'expiration et des plafonds par fonctionnalité ; la clé est envoyée automatiquement par e-mail lorsqu'une adresse est fournie.

Corrige un bug de mise en cache qui pouvait masquer les nouvelles versions aux utilisateurs situés derrière certains proxys d'entreprise.

Corrigé

• Fiabilité du flux de mise à jour automatique — le manifeste de mise à jour est désormais servi avec un en-tête no-cache strict, de sorte qu'un proxy de mise en cache placé entre fucini.software et le lecteur ne peut plus servir une copie périmée qui masque les nouvelles versions.

Une petite mise à jour de maintenance : quelques corrections de bugs mineures et des améliorations de performances.

Corrigé

• Corrections de bugs — corrections de bugs mineures et améliorations de la stabilité.
• Performances — légères améliorations de performances pour le chargement et l'affichage de la couverture.

Les clés d'activation sont désormais délivrées et appliquées automatiquement — plus besoin d'attendre un e-mail.

Modifié

• Activation automatisée — demander une clé envoie désormais un court questionnaire et applique automatiquement la clé reçue à vos paramètres, sans échange par e-mail.
• Renouvellements plus rapides — une demande de renouvellement ne pose que des questions sur l'usage et les souhaits ; vos coordonnées d'une demande précédente sont réutilisées, jamais redemandées.
• Fenêtre d'évaluation fixe — l'essai court désormais jusqu'au 31/12/2026 pour tout le monde, remplaçant le précédent compte à rebours de 14 jours depuis l'installation.
• Flux d'activation localisé — le questionnaire de renouvellement et les confirmations d'activation sont désormais traduits dans les 18 langues prises en charge, comme le reste de l'extension.

L'extension vérifie désormais les mises à jour à la fois sur fucini.software et sur le VS Code Marketplace, en proposant toujours la version la plus récente.

Corrigé

• Vérification à deux sources — interroge désormais à la fois fucini.software et le VS Code Marketplace, et propose la version la plus récente.

Première version publique de Fucini Coverage Studio — couverture native pour VS Code qui ingère des fichiers de trace de normes industrielles, les normalise en un modèle canonique unique, fusionne les exécutions de façon déterministe et génère des rapports via l'API Test Coverage intégrée de VS Code.

Ajouté

• Ingestion multi-format — LCOV, llvm-cov JSON, Cobertura XML, JaCoCo XML, Istanbul/nyc et SimpleCov JSON, détectés automatiquement.
• Fusion déterministe — plusieurs fichiers de trace combinés en une seule exécution avec provenance enregistrée, stable quel que soit l'ordre de chargement.
• Interface de couverture native — gouttières de ligne/branche/fonction, règle de synthèse et panneau Test Coverage intégré.
• Couverture MC/DC — détail par décision au survol et une gouttière de marge colorée facultative.
• Score composite — une moyenne harmonique pondérée par SIL sur les lignes, branches, fonctions, régions, MC/DC et instanciations C++.
• Verdict de conformité — contrôle COMPLIANT / NON-COMPLIANT avec les modes strict, whm, both et either.
• Remappage de chemins, couverture différentielle, badges Explorer et une barre d'état globale.
• Analyse dans l'éditeur — CodeLens de fonction, survol de branche, avertissements de code mort, avertissements de couverture obsolète et Next/Previous Uncovered.
• Vue des fichiers couverts, rapports HTML, historique & tendances, mode watch et export Fucini JSON.