Tout ce qu'il fait, tout ce que vous pouvez régler

Quand cʼest une IA qui a écrit les tests

La couverture face à une suite de tests générée

L'aperçu pose l'argument général. Le voici confronté à la liste des fonctionnalités elle-même, car une suite générée échoue selon une forme caractéristique — chaque ligne touchée, la moitié des décisions jamais prises, et quelques fonctions nommées dans les titres de tests mais jamais réellement appelées — et cinq des éléments ci-dessous sont précisément ce qui rend cette forme visible.

• La couverture des branches et MC/DC, avec le survol par arc et par décision, sépare la ligne s'est exécutée de la décision a été exercée. Une suite qui ne suit que le chemin heureux affiche près de 100% sur les lignes et près de 50% sur les branches, et c'est cet écart qui constitue le résultat. Une exécution de tests au vert n'en montre rien.
• Le score composite est une moyenne harmonique, si bien qu'une métrique forte ne peut pas masquer une métrique faible — exactement l'arithmétique qu'il faut appliquer à une suite générée. Faire la moyenne du chiffre des lignes et de celui des branches enterrerait le seul chiffre qui compte.
• Les avertissements de code mort ajoutent une entrée dans le panneau Problems pour toute fonction ayant des lignes mesurables et une couverture nulle. Une suite qui nomme une fonction dans un titre de test sans jamais l'atteindre n'échoue nulle part ailleurs.
• La couverture de diff par rapport à une référence git de base restreint tout ce qui précède aux lignes qui viennent de changer — le code que vous avez accepté cet après-midi, plutôt que la moyenne de toute la vie du dépôt, avec laquelle une grande suite existante continuera allègrement de paraître en bonne santé.
• Copy Uncovered Lines produit exactement ce qui n'a jamais été exécuté, en Markdown — de quoi le recoller directement à l'assistant qui a écrit la suite en premier lieu.

Rien de tout cela ne lit un test pour le juger, et rien ici ne doit être compris comme une telle prétention : un test sans la moindre assertion couvre toujours chaque ligne qu'il touche. Ce que ces mesures donnent, c'est la part qu'un relecteur ne peut pas garder en tête — quel code n'a jamais été exécuté.

Unique à cette extension

Votre couverture de lignes indique 100%. 312 octets de votre binaire n'ont jamais tourné.

Toutes les autres métriques ici se mesurent à la source : instrumenter le code, exécuter la build instrumentée, compter ce qui s'est déclenché. La couverture du code objet mesure ce qu'aucun outil basé sur la source ne peut atteindre — quelle part du binaire construit s'est réellement exécutée, en octets d'instructions, en observant le flux d'instructions. Un compilateur produit du code dont aucune ligne de votre source ne rend compte : vérifications de bornes de tableaux, tables de saut de switch, sauvegardes de registres, routines d'exécution pour la division ou le flottant. Rien de tout cela n'apparaît dans votre source, donc aucun outil basé sur la source — y compris cette extension, pour toute autre métrique qu'elle lit — ne peut dire si cela a tourné. C'est aussi la seule métrique ici qui réponde à cela couvre-t-il l'assembleur ?, l'assembleur écrit à la main n'étant jamais instrumenté.

DO-178C le nomme explicitement : au niveau A, il est exigé en plus de MC/DC. Aucune autre extension VS Code ne le lit. Comment l'obtenir depuis une cible embarquée →

Capacités

Fonctionnalités de base

• Une vue Coverage de chaque fichier mesuré, la règle d'aperçu et Annotated Source ; dans la gouttière propre à l'éditeur, par défaut, seulement ce qui mérite une marque — barres MC/DC, triangles « depuis la dernière exécution », points des lignes modifiées — avec des barres sur les seules lignes non couvertes ou une carte de chaleur des passages à un réglage près.
• Couverture par ligne des instructions, branches, fonctions, régions, MC/DC et instanciations C++, selon ce que fournit le fichier de trace.
• Ingestion multi-format et fusion déterministe de plusieurs exécutions avec provenance enregistrée.
• Remappage de chemins — chemins de la machine de build CI → votre espace de travail local.
• Couverture différentielle — ne décore que les lignes modifiées par rapport à une référence git de base.
• Badges Explorer et un élément barre d'état global, coloré selon le score composite.
• Mode watch — rechargement automatique lorsqu'un fichier de trace change.
• Run Tests with Coverage — reconnaît le lanceur de tests à la racine de l'espace de travail et l'exécute avec la couverture activée, en chargeant ce qu'il écrit.
• Fichiers de trace distants — une entrée de coverageFile.paths peut être une URL https:// : l'artefact CI est récupéré de façon conditionnelle (ETag / Last-Modified), avec les en-têtes que vous configurez dans remote.headers, chargé comme un fichier local, et récupéré à nouveau à intervalle régulier avec remote.refreshMinutes ; quand une récupération échoue, la dernière copie téléchargée est chargée à la place.
• Variables dans les chemins — ${workspaceFolder}, ${workspaceFolderBasename}, ${userHome}, ${env:NAME}, ${command:id} et ${config:section.key} dans chaque réglage de chemin ; une variable inconnue est laissée telle quelle, si bien qu'une faute de frappe apparaît dans le journal de détection au lieu de disparaître.
• Espaces de travail multi-racines — chaque dossier est détecté depuis ses propres réglages (son .vscode/settings.json ou son entrée dans le .code-workspace), ses fichiers de trace fusionnent en une seule exécution, la vue Coverage regroupe les fichiers par dossier, et un dossier ajouté ou retiré recharge la couverture de lui-même.
• Deux déclencheurs de rechargement de plus — une entrée absolue de coverageFile.paths hors de l'espace de travail est interrogée, si bien qu'un fichier qui y apparaît est chargé ; et watch.reloadAfterTasks nomme des tâches (npm: test) dont la fin recharge la couverture, que le mode watch soit activé ou non.
• Une progression que l'on peut annuler — un chargement de dix fichiers de trace ou plus, ou de 8 Mo ou plus, et chaque Generate Full HTML Report s'exécutent sous une notification de progression munie d'un bouton Annuler ; annuler laisse l'exécution précédente chargée.
• La vue Test Coverage propre à VS Code — chaque chargement est aussi publié via l'API Test Coverage de l'éditeur (testCoverage.publish), si bien que le panneau de couverture du Test Explorer, les pourcentages par fichier de l'Explorateur et la bascule Show Inline Coverage de l'éditeur affichent les mêmes chiffres ; Show in Test Coverage View publie à la demande et ouvre le panneau. Avec des tests nommés (TN: dans lcov), la vue filtre la couverture d’un fichier par test.
• Règle de remappage suggérée — quand un chargement laisse des fichiers sans correspondance (chemins de conteneur ou de CI face à une copie de travail locale), l'extension infère la règle pathRemap qui en explique le plus grand nombre, propose Apply Suggested Remap sur le résultat du chargement et Suggest Path Remap Rule dans la palette ; rien n'est écrit sans le clic.
• Motifs d'exclusion — fuciniCoverage.ignore (vendor/**, **/*.generated.ts) écarte des fichiers entiers de l'exécution au chargement, si bien que chaque vue, chaque garde-fou et chaque export compte sans eux ; le résultat du chargement dit combien et la sortie nomme chacun.
• Non mesuré et non couvert — un fichier qu'aucun test n'a chargé n'est pas noté 0 % dans votre dos ; la barre d'état dit not measured pour un tel fichier, et unmeasured.mode peut lister ces fichiers dans la vue Coverage ou compter chacun comme un fichier non couvert, avec threshold.unmeasuredFiles pour poser un garde-fou sur leur nombre.
• Ce que la fusion a fait, visible — avec plusieurs tracefiles chargés, chaque ligne de fichier nomme le rapport dont viennent ses chiffres, le badge est entouré là où ces chiffres ont supplanté un rapport plus ancien, chaque ligne de tracefile compte combien de ses fichiers ont été supplantés ou en ont supplanté d’autres, et un clic sur une ligne de tracefile met ses fichiers en évidence dans l’arbre (coverageView.mergedMarks).

Score composite & conformité

Une seule moyenne harmonique pondérée sur les lignes, branches, fonctions, régions, MC/DC et instanciations. Comme il s'agit d'une moyenne harmonique, une métrique faible ne peut pas être masquée par une parfaite. Les poids sont par défaut alignés sur les niveaux IEC 61508 / ISO 26262 / DO-178C, et le verdict COMPLIANT / NON-COMPLIANT est déterminé par des seuils par métrique ainsi qu'un mode configurable.

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

Analyse dans l'éditeur

• CodeLens de fonction — % de couverture par fonction, cliquez pour sauter à sa première ligne non couverte.
• Survol de branche & MC/DC — comptes pris/non pris par branche et détails condition/vecteur par décision ; gouttière de marge MC/DC colorée optionnelle.
• Avertissements de code mort — avertissement dans le panneau Problems pour les fonctions avec des lignes mesurables et une couverture nulle.
• Navigation Next/Previous Uncovered.
• Avertissement de non-concordance quand le contenu d'un fichier ne correspond plus à son exécution — tenu à jour à chaque enregistrement ou modification sur le disque, avec la différence exacte au survol.
• Depuis la dernière exécution — un triangle rouge sur chaque ligne exécutée lors de l'exécution précédente et pas dans celle-ci, un vert pour l'inverse, avec la règle d'aperçu et les nombres de passages au survol.
• Tampons modifiés — chaque marque, survol et CodeLens suit le texte pendant l'édition et se retire d'une ligne réécrite, où un point gris dit pourquoi.
• Modes de gouttière de l'éditeur — editorGutter.mode limite la gouttière aux constats (off), place une barre sur chaque ligne jamais exécutée et une barre ambre là où l'une des branches n'a jamais été prise (uncovered), ou ajoute une teinte chaude sur chaque ligne exécutée, d'autant plus vive qu'elle a tourné souvent (heatmap) ; Choose Editor Gutter Mode... bascule depuis la palette ou le menu de la barre d'état.
• Compteurs de passages en ligne — hitCounts.inline écrit ×12 après chaque ligne où commence une instruction, ×0 compris ; Toggle Inline Hit Counts l'active ou le désactive.
• Entrées Problems par ligne — problems.perLine place un diagnostic Information sur chaque bloc de lignes jamais exécutées d'un document ouvert (une fonction morte est une entrée, pas quarante), et éventuellement sur chaque ligne dont l'une des branches n'a jamais été prise ; les entrées suivent leurs lignes pendant l'édition.
• Teinte de ligne et carte dans la barre de défilement — lineHighlight place une teinte translucide derrière les lignes elles-mêmes plutôt que (ou en plus d’)une marque dans la gouttière, et overviewRuler décide seul de la bande dans la barre de défilement : gouttière désactivée, c’est une carte des manques du fichier et rien à côté du code.
• Quel fichier de trace a couvert cette ligne — avec plusieurs rapports fusionnés, l’info-bulle du nombre d’exécutions nomme chacun de ceux qui ont couvert la ligne (nom de suite issu du TN: de lcov compris), et un clic sur une ligne de fichier de trace dans la vue Coverage éclaire les lignes qu’il a apportées.

• Rouge, ambre et vert — le mode coverage de editorGutter.mode et de lineHighlight peint chaque ligne mesurée aux couleurs de l’échelle de couleurs ; le bouton de mode de la barre d’état et Alt+G passent d’un mode au suivant.
• Vos couleurs, en aperçu — l’échelle de couleurs et les teintes de la carte de chaleur (heatmap.colors, heatmap.colorsDark) sont des réglages, et la page des réglages les prévisualise sur un éditeur clair et un éditeur sombre au moment où elles sont choisies.
• De quel rapport vient un fichier — quand deux rapports mesurent le même code, des règles coverageFile.sources, ou Choose Coverage Source for This File..., décident lequel chaque fichier affiche, au lieu que le plus récent l’emporte.

Rapports & historique

• Generate Full HTML Report — un rapport multi-pages auto-généré, par répertoire ; Open Annotated Source pour un seul fichier.
• Historique local optionnel des exécutions avec une tendance de couverture (▲/▼), ainsi que Compare Two History Runs et Compare with Last Run.
• Show Worst-Covered Files / Functions et Copy Uncovered Lines (Markdown).
• Export Fucini JSON — le modèle normalisé complet.
• Export Coverage Report... — la même exécution en CSV (par fichier ou par fonction), en résumé Markdown, en fichier de trace LCOV, en XML Cobertura, en SARIF, ou en badge SVG autonome. Avec vingt-cinq lecteurs et ces écrivains, l'extension convertit entre formats : chargez JaCoCo ou llvm-cov JSON et produisez le LCOV que lisent Codecov, Coveralls et SonarQube, ou le XML Cobertura qu'ingèrent Jenkins, GitLab et Azure DevOps.
• Generate Coverage Badge — un SVG de style shields écrit directement dans l'espace de travail (badge.outputPath, par défaut coverage-badge.svg), qu'un README intègre avec ![coverage](coverage-badge.svg) sans service hébergé ; badge.metric choisit les lignes, les branches, le MC/DC ou le score composite, la couleur suit les paliers de colorScale.*, et badge.autoUpdate le réécrit après chaque chargement.

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

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

Community et Pro, fonctionnalité par fonctionnalité

Deux fiches, un seul code. Community est l'édition gratuite pour toujours, et celle où retombe la fiche Pro après son essai de 14 jours ; Pro et l'essai, c'est tout, sans plafond. La limite est tracée pour que l'édition gratuite voie toujours chaque constat et ne paie que le confort, la preuve et l'échelle — dans VS Code, Fucini Coverage: What Community Includes montre la même liste avec les compteurs du jour pour chaque plafond.

Une semaine dure sept jours à compter de la première utilisation qui l'a ouverte, et rien de ce qui ne fait que lire la couverture n'est compté. Pas prêt pour un abonnement ? Un pass 7 jours, c'est tout ce que contient la colonne de droite pendant une semaine, payé une seule fois, sans rien à résilier.

VS Code et Visual Studio côte à côte

Un produit, deux éditeurs, un lecteur : le même rapport donne les mêmes chiffres, au chiffre près, dans les deux. Coverage Studio pour Visual Studio fonctionne sur Visual Studio 2022 et 2026 — Community, Professional et Enterprise et n'utilise pas la couverture de code propre à Visual Studio, réservée à Enterprise en 2022 ; il est inclus dans chaque forfait payant, et un appareil avec les deux éditeurs compte pour un siège. Tout ce qui est au-dessus de la ligne existe dans les deux ; en dessous, ce pour quoi Visual Studio n'a pas d'équivalent, et ce qui y est encore à venir.

Référence des paramètres

Configurez dans l'interface des paramètres (recherchez Fucini Coverage) ou dans settings.json.

Download the complete settings reference — a commented settings.json holding every fuciniCoverage.* setting at the same default the packaged extension uses, ready to copy into your workspace or user settings. Regenerated from the extension on every release, so it cannot drift from what the VSIX ships.

Une ligne se terminant par Par dossier. accepte une valeur au niveau du dossier dans un espace de travail multi-racines : chaque dossier est détecté avec son propre .vscode/settings.json ou sa propre entrée dans le .code-workspace, et ${workspaceFolder} y désigne ce dossier.

Localisation

Découverte & chargement

Échelle de couleurs et badges

Score composite (moyenne harmonique pondérée)

Seuils & conformité

Diff, remappage & rapports

Affichage & analyse

Historique

Actions rapides de la barre d'état

Tous désactivés (false) par défaut, sauf les deux derniers ; activez pour ajouter l'action correspondante au menu rapide : quickActions.compareWithLastRun, openAnnotatedSource, openAnnotatedSourceToSide, toggleAnnotatedSource, toggleWatch, worstCoveredFiles, worstCoveredFolders, worstCoveredFunctions, nextUncovered, previousUncovered, checkThresholds, copyUncoveredLines, compareHistoryRuns, exportJson, exportReport, generateBadge, showTestCoverage, chooseGutterMode, toggleInlineHitCounts.

Télémétrie

Mises à jour

Licence