Benutzerhandbuch

1. Einführung

Fucini Coverage Studio macht aus den Coverage-Tracedateien, die Ihr Build bereits erzeugt, vollwertige Coverage im Editor — in VS Code und in Visual Studio. Es liest fünfundzwanzig Formate, normalisiert sie in ein kanonisches Fucini-Modell, führt mehrere Läufe deterministisch zusammen und zeigt das Ergebnis im Editor selbst — Randleiste, CodeLens, Hover und eine Covered-Files-Ansicht —, sodass es keinen separaten Viewer gibt, für den Sie den Editor verlassen müssten. Die beiden Editionen teilen sich einen Reader: Derselbe Bericht liefert in beiden dieselben Zahlen, auf die Stelle genau. Dieses Handbuch ist aus Sicht von VS Code geschrieben; wo Visual Studio abweicht, sagt ein Kasten In Visual Studio, wie.

Sie wurde mit Blick auf funktionale Sicherheitsprozesse entwickelt: MC/DC-Coverage, Region- und C++-Instanziierungs-Coverage, ein sicherheitsgewichteter Gesamtscore sowie ein konfigurierbares COMPLIANT-/NON-COMPLIANT-Urteil, das sich an den Denkweisen von IEC 61508, ISO 26262 und DO-178C orientiert.

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

2. Installation & Voraussetzungen

• VS Code ≥ 1.88 — die Mindestversion, die diese Erweiterung unterstützt — oder Visual Studio 2022 oder 2026, Community, Professional oder Enterprise (siehe den Kasten unten).
• Eine Coverage-Tracedatei, die Ihr Projekt bereits erzeugt (siehe §4).

Installieren Sie die Erweiterung über den Marketplace oder aus einer .vsix-Datei über Extensions → ⋯ → Install from VSIX…. Die Erweiterung aktiviert sich beim Start und fügt der Aktivitätsleiste ein Coverage-Symbol hinzu.

3. Schnellstart

1. Erzeugen Sie mit Ihrem üblichen Test-Workflow eine Coverage-Tracefile.
2. Befehlspalette (Ctrl+Shift+P) → Fucini Coverage: Load Coverage. Ist watch.enabled aktiviert (Standard), wird eine passende Datei automatisch geladen.
3. Öffnen Sie eine erfasste Quelldatei: Die Statusleiste zeigt ihren Prozentwert, die Coverage-Ansicht füllt sich, das Überfahren einer Zeile zeigt ihre Trefferzahl, und der Lauf erscheint im nativen Test Coverage-Panel. Balken auf nicht abgedeckten Zeilen, eine Heatmap der Trefferzahlen und Inline-×N-Zähler sind eine Einstellung entfernt (editorGutter.mode, hitCounts.inline).

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

4. Tracefiles erzeugen

Beim Laden werden folgende Formate automatisch erkannt:

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

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

llvm-cov-JSON ist die umfangreichste Eingabe — sie enthält neben Zeilen, Branches und Funktionen auch Regionen, MC/DC und C++-Template-Instanziierungen.

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

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

JavaScript / TypeScript — Istanbul / nyc

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

Java — JaCoCo

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

Ruby — SimpleCov

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

Go

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

Python — coverage.py

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

PHP — PHPUnit (Clover)

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

.NET / C# — Coverlet (OpenCover)

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

Ein natives C++-Projekt, aus Visual Studio heraus gemessen

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

5. Laden & Erkennung

Standardmäßig durchsucht die Erweiterung das Workspace-Stammverzeichnis. Steuern Sie dies präziser mit zwei Einstellungen:

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

• Jeder Eintrag in paths ist relativ zu defaultLocation (oder zum Workspace-Stamm, wenn nicht festgelegt).
• Ein Eintrag mit * wird rekursiv durchsucht; ein reiner Dateiname wird nur direkt im Basisordner gefunden.
• Ist paths leer, sucht die Erweiterung zuerst nach coverage.json, dann nach lcov.info, und lädt, was sie zuerst findet.
• Pick Coverage File verwendet die von Ihnen gewählten Dateien anstelle dieser Pfade — jede Auswahl kommt hinzu, und alle werden zusammengeführt —, bis Sie sie entladen oder diese Einstellungen ändern.
• Variablen — jede Pfadeinstellung expandiert ${workspaceFolder}, ${workspaceFolderBasename}, ${userHome}, ${env:NAME}, ${command:id} und ${config:section.key}. Eine Variable, die die Erweiterung nicht kennt, bleibt stehen, wie sie geschrieben wurde, sodass ein Tippfehler im Erkennungsprotokoll als der gesuchte Pfad auftaucht, statt zu verschwinden. ${command:id} führt diesen Befehl zuerst aus — nur in einem vertrauenswürdigen Arbeitsbereich und höchstens fünf Sekunden lang —, sodass ${command:cmake.buildDirectory} dem gewählten CMake-Kit folgt.
• URL-Einträge — ein http(s)://-Eintrag wird bei jedem Laden in den Speicher der Erweiterung geholt und von dort geladen; die Coverage-Ansicht nennt die URL. Jeder Abruf ist bedingt (ETag / Last-Modified), sodass ein unverändertes Artefakt nichts herunterlädt, und schlägt ein Abruf fehl, wird stattdessen die zuletzt heruntergeladene Kopie geladen, mit dem Grund in der Ausgabe. remote.headers fügt Name: value-Header mit expandierten Variablen hinzu, remote.refreshMinutes ruft nach einem Zeitplan erneut ab, und ein #lcov.info-Fragment nennt das Format, wenn die URL selbst nicht auf einen Dateinamen endet.
• Ignore-Globs — fuciniCoverage.ignore entfernt ganze Dateien (vendored, generiert, von Dritten) beim Laden aus dem Lauf, sodass jede Ansicht, jedes Gate und jeder Export ohne sie zählt; das Ladeergebnis sagt, wie viele weggelassen wurden, und die Ausgabe nennt sie. Muster passen auf den arbeitsbereichsrelativen und den absoluten Pfad, und ein Muster ohne / passt auf einen Ordner- oder Dateinamen in beliebiger Tiefe, wie in .gitignore.
• Multi-Root-Arbeitsbereiche — jeder Ordner wird nach seinen eigenen Regeln erkannt: defaultLocation, paths, pathRemap, ignore, watch.* und remote.* werden je Ordner gelesen, sodass die eigene .vscode/settings.json eines Ordners oder sein .code-workspace-Eintrag gilt, und ${workspaceFolder} in einem Eintrag meint den eigenen Ordner dieses Eintrags. Die Tracedateien aller Ordner verschmelzen zu einem Lauf, die Coverage-Ansicht gruppiert die Dateien nach Ordner, und ein zum Arbeitsbereich hinzugefügter oder daraus entfernter Ordner lädt die Coverage von selbst neu.
• Neuladen nach einer Aufgabe — watch.reloadAfterTasks nennt Aufgaben (ein label aus der tasks.json, oder source: name, wie die Liste von Run Task es zeigt), deren Ende die Coverage neu lädt, ob watch.enabled nun an ist oder nicht — für Builds, denen der Watcher nicht folgen kann. Ein absoluter paths-Eintrag außerhalb des Arbeitsbereichs wird ebenfalls abgefragt, sodass eine dort erscheinende Datei geladen wird.
• Fortschritt, den Sie abbrechen können — ein Ladevorgang mit zehn oder mehr Tracedateien, oder 8 MB oder mehr davon, läuft unter einer Fortschrittsbenachrichtigung mit einer Abbrechen-Schaltfläche, die die gerade gelesene Datei und die Phase nennt; ein kleinerer lässt nur die Statusleiste kreisen. Ein Abbruch lässt den vorherigen Lauf geladen und sagt das.

Seit 1.2026.6 darf auch ein absoluter Eintrag einen Platzhalter enthalten: ${workspaceFolder}/build/coverage-merged/*.lcov.info lädt jede solche Datei in diesem Ordner, und ** steht für beliebige Tiefe. Gesucht wird in den Ordnern vor dem ersten Platzhalter, und sie werden beobachtet, sodass ein Bericht, den ein Build dort schreibt, von selbst lädt. Die Visual-Studio-Edition liest einen solchen Eintrag genauso, und seit 1.2026.5 wird ein relativer Platzhalter auch dort in beliebiger Tiefe gesucht, wie es hier schon immer der Fall war.

Ist kein paths konfiguriert, wird der erste der bekannten Berichtsnamen geladen, der unterhalb des Basisordners gefunden wird. Zuerst die vier, nach denen schon immer gesucht wurde – coverage.json, lcov.info, coverage.out, clover.xml –, dann, seit 0.2026.83, jacoco.xml, coverage.xml, cobertura.xml, coverage.cobertura.xml, coverage.opencover.xml und coverage-final.json, und danach die Orte, an die Standardkonfigurationen schreiben: coverage/ (nyc, Jest, vitest, PHPUnit, SimpleCov), target/site/jacoco/jacoco.xml (Maven), build/reports/jacoco/test/jacocoTestReport.xml (Gradle) und TestResults/*/coverage.cobertura.xml (dotnet test). So zeigt ein Java- oder .NET-Projekt seine Abdeckung gleich beim ersten Öffnen, wie es ein lcov-Projekt schon immer getan hat.

Seit 1.2026.3 braucht eine .NET-Projektmappe noch weniger: Der Ordner TestResults/<run>/ jedes Testprojekts gehört zu den bekannten Orten, nicht nur der des Arbeitsbereichsordners selbst, und die <user>_<machine>_<date>.cobertura.xml von Microsofts Collector wird neben Coverlets coverage.cobertura.xml gefunden — eine Projektmappe, deren Tests im Test Explorer von Visual Studio gelaufen sind, zeigt ihre Coverage also beim ersten Öffnen, jeder Lauf-Ordner wird geladen, und die Zusammenführung behält für jede Datei das Wort des neuesten Laufs. Und fuciniCoverage.ignore.generated, standardmäßig an, lässt Designer- und generierte Dateien — *.Designer.cs, *.g.cs, *.generated.cs, *.razor.g.cs, AssemblyInfo, globale Usings, Migrations/ und obj/ — aus jeder Summe, jeder Seite und jedem Export heraus, bevor ignore angewandt wird, sodass eine generierte Tabelle, die niemand testet, die Projektmappe nicht ihr Gate kostet.

Ein CI-Artefakt hinter einem Token, jede Viertelstunde erneut geprüft — das Token bleibt in der Umgebung, nie in der settings.json:

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

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

Ein Neuladen ist absichtlich still – ein Dialog nach jedem Build ist eine Frage mit nur einer Antwort. Nicht still ist das Coverage-Symbol: Solange die Ansicht nicht vor Ihnen liegt, trägt es die Zahl der erneut gelesenen Tracefiles, und sein Tooltip nennt sie beim Namen. Öffnen Sie die Ansicht, und die Zahl ist weg.

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

Dateien, die nie zählen sollen, was auch immer die Tracedatei über sie sagt:

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

Ein Neuladen, wenn die Testaufgabe endet, für einen Build, dem der Datei-Watcher nicht folgen kann — ein Lauf, der einen per Symlink eingebundenen Ausgabebaum ersetzt, ein Bericht auf einer Netzwerkfreigabe, ein Coverage-Schritt, der seine Datei nachbearbeitet:

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

6. Läufe zusammenführen

Jeder vorhandene paths-Eintrag wird geladen und zu einem Lauf zusammengeführt. Das Zusammenführen ist deterministisch — das Ergebnis hängt nicht von der Ladereihenfolge ab — und eine Datei, die mehr als ein Tracefile gemessen hat, nimmt ihre Zahlen von dem mit der neuesten mtime auf der Festplatte: der eigene Neulauf eines Moduls ersetzt, was ein breiterer, älterer Lauf über sie gesagt hat, statt es zu ergänzen. Die Abdeckungsansicht zeigt, was das bewirkt hat: jede Dateizeile nennt das Tracefile, aus dem ihre Zahlen stammen, das Abzeichen ist umrandet, wo diese Zahlen einen älteren Bericht überstimmt haben, jede Tracefile-Zeile über dem Baum zählt, wie viele ihrer Dateien überstimmt wurden oder andere überstimmt haben, und ein Klick auf eine Tracefile-Zeile hebt ihre Dateien im Baum hervor, bis sie erneut angeklickt wird (coverageView.mergedMarks schaltet Umrandung und Hervorhebung ab).

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

Ein zusammengeführter Lauf kann mehr als die sechs klassischen Metriken enthalten, jede aus dem Bericht, der sie misst: Funktionsaufrufe, Objektcode und einen Mutationsscore neben Zeilen, Funktionen, Regionen, Zweigen, MC/DC und Instanziierungen. Die Coverage-Ansicht zeigt für jede Metrik, die der Lauf enthält, eine Spalte – und keine für eine, die er nicht enthält –, sortiert nach dem Gewicht, das jede Metrik in Ihrer Bewertung hat, die schwerste zuerst, bei jeder Breite – was nicht mehr hineinpasst, wird seitlich gescrollt statt ausgeblendet. Ziehen Sie die Ansicht in das untere Panel, und sie wird zur Tabelle. Die Karten in der Statusleiste, der HTML-Bericht und die CSV- und Markdown-Exporte folgen derselben Regel: Was ein Bericht enthält, wird angezeigt; was er nicht enthält, wird weggelassen und nicht als Null ausgegeben.

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

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

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

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

Aus welchem Bericht eine Datei stammt

Wenn mehrere geladene Berichte dieselbe Datei messen, gewinnt der neueste sie ganz — richtig, wenn der erneute Lauf eines Moduls ersetzt, was ein älterer, breiterer Lauf gesagt hat. Falsch ist es, wenn die Berichte denselben Code absichtlich messen: Dann springt der Editor mit jedem Build zwischen ihnen hin und her, und jeder erzählt nur einen Teil der Geschichte. coverageFile.sources sagt, was stattdessen zu tun ist, je Datei. Drei Situationen verlangen danach:

• Ein Bericht ist der bessere. Das coverage.json von llvm-cov enthält MC/DC, ein GCC-gcov.info desselben Builds nur Zeilen und Zweige: Wählen Sie coverage.json, und behalten Sie den anderen für die wenigen Dateien, die nur GCC baut.
• Mehrere Testsuiten eines Builds. Unit-Tests, Integrationstests und Hardware-in-the-Loop schreiben je einen Bericht; jeder für sich lässt Zeilen aus, die die anderen ausgeführt haben. Kombinieren, union: Eine Zeile ist abgedeckt, wo irgendein Bericht sie ausgeführt hat, und die Zählwerte werden addiert.
• Eine Codebasis, zwei Compiler. Dieselben Quellen, von clang und von GCC gebaut, nehmen unterschiedliche Wege durch toolchain-spezifischen Code — hier ein Intrinsic, dort ein portabler Fallback —, und jeder Bericht sagt, die andere Hälfte sei nie gelaufen. Kombinieren, agree: Eine Zeile ist nur dort abgedeckt, wo jeder Bericht, der sie misst, sie ausgeführt hat, und die Zeilen, in denen sie voneinander abweichen, sind türkis markiert. Das ist die Frage, die ein Cross-Compiler-Abgleich stellt: Was hat jeder Build, den ich ausliefere, tatsächlich ausgeführt?

Die Regeln schreiben Sie selten von Hand. Klicken Sie in der Abdeckungsansicht mit der rechten Maustaste auf eine Datei und wählen Sie Choose Coverage Source... (oder führen Sie Choose Coverage Source for This File... auf der offenen Datei aus): Die Liste zeigt jeden Bericht, der die Datei misst, jeden mit seinen eigenen Zeilen, Zweigen und MC/DC, dann Combine them — agree und Combine them — union; wählen Sie einen aus und geben Sie an, ob er für die Datei, ihren Ordner oder ein Muster gilt. Clear Coverage Source for This File... nimmt die Regel wieder heraus. In den Einstellungen ist jede Regel ein Glob über die Dateien, ein Glob über den Bericht (ein Muster ohne / trifft den Dateinamen des Berichts, {a,b} nennt mehrere) und, zum Kombinieren, "combine": "agree" oder "union". Es entscheidet die erste Regel, deren Dateien passen und deren Bericht die Datei misst; eine Datei, die nur ein Bericht misst, wird ihm nie genommen. Zweige, MC/DC und Regionen einer kombinierten Datei stammen aus dem Bericht, der am meisten davon enthält. coverageFile.mergeStrategy: "order" entscheidet die Dateien, für die keine Regel spricht, nach der Reihenfolge von coverageFile.paths statt nach den Zeiten.

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

Was Sie sehen: Die Zeile der Datei in der Abdeckungsansicht nennt den Bericht, aus dem ihre Zahlen stammen, oder, kombiniert, jeden Bericht und den Modus, mit ≠ n für die strittigen Zeilen. Der Gutter und die Annotated Source markieren diese Zeilen türkis und sagen, welcher Bericht sie wie oft ausgeführt hat. Die Hover-Karte der Statusleiste nennt die Quelle der offenen Datei und, für den ganzen Lauf, die geltenden Regeln und wie über die übrigen Dateien entschieden wurde. samples/c-cross-check aus der Demo ist der Fall mit zwei Compilern, bereit zum Öffnen. Visual Studio kann all das ebenfalls: Choose Coverage Source... auf einer Zeile der Abdeckungsansicht sowie Choose und Clear Coverage Source for This File... unter Tools > Coverage Studio.

Quellen wählen und kombinieren gehört zu den kostenpflichtigen Plänen. In Community gewinnt der neueste Bericht jede Datei, wie ohne Regel, und eine Regel in den Einstellungen wird als ungenutzt gemeldet, statt stillschweigend ignoriert zu werden.

7. Pfad-Remapping

CI-Systeme zeichnen oft absolute Pfade der Build-Maschine auf, die auf Ihrer Arbeitsstation nicht existieren. Schreiben Sie diese mit geordneten Regeln um:

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

Die Regeln werden der Reihe nach angewendet; pro Präfix gewinnt die erste Übereinstimmung. Nutzen Sie dies, um Unterschiede bei Windows-/Unix-Trennzeichen auszugleichen oder einen Containerpfad auf Ihren Checkout abzubilden.

Die Regel müssen Sie nur selten selbst schreiben. Das häufigste „es hat geladen, aber nichts leuchtet auf“ ist eine Tracedatei, deren Pfade aus einem Container oder einem CI-Checkout stammen (/build/src/a.c, /home/runner/work/repo/repo/src/a.c, C:\agent\_work\1\s\src\a.c), während der Arbeitsbereich src/a.c hat. Lässt ein Ladevorgang Dateien unzugeordnet, sucht die Erweiterung die Dateinamen im Arbeitsbereich, leitet die Präfixregel ab, die die meisten davon erklärt, protokolliert sie als [FUCINI_REMAP_002], und das Ladeergebnis bietet Apply Suggested Remap an — ein Klick hängt die Regel an fuciniCoverage.pathRemap an und lädt neu. Suggest Path Remap Rule führt dieselbe Analyse auf Anfrage aus der Palette aus. Ohne den Klick wird nichts geschrieben.

Ein to darf ${workspaceRoot} verwenden, das für den Arbeitsbereichsordner steht, in dem die Tracedatei liegt; in einem Multi-Root-Arbeitsbereich versucht es zuerst diesen Ordner, dann jeden anderen Ordner, in dem sich die Datei findet. Die Regeln selbst werden je Ordner gelesen, sodass jeder Stamm eines Multi-Root-Arbeitsbereichs seine eigenen tragen kann.

8. Coverage im Editor

• Ränder & Übersichtsleiste — standardmäßig zeigt der eigene Gutter des Editors nur Befunde: MC/DC-Balken, Seit-letztem-Lauf-Dreiecke, Punkte auf bearbeiteten Zeilen. editorGutter.mode fügt Balken nur auf nicht abgedeckten Zeilen oder eine Heatmap der Trefferzahlen hinzu (unten); die farbcodierte Ansicht einer ganzen Datei ist die Annotated Source.
• Funktions-CodeLens — Coverage-% über jeder Funktion; Klick springt zur ersten nicht abgedeckten Zeile. Umschaltbar über codeLens.enabled.
• Branch- & MC/DC-Hover — beim Überfahren einer Entscheidungszeile werden Taken/Not-taken-Zahlen je Zweig und eine Vektortabelle je Bedingung angezeigt. Farbige Randleiste aktivierbar über mcdcGutter.enabled.
• Warnungen für toten Code — Funktionen mit messbaren Zeilen und null Coverage werden im Problems-Panel markiert (deadCode.enabled).
• Next / Previous Uncovered — zwischen Lücken springen.
• Statusleiste — ein laufweites $(dashboard) NN%-Element und ein Element je Datei, beide farbcodiert nach dem Gesamtscore; Hover zeigt eine vollständige Metriktabelle.
• Explorer-Badges — Abdeckungs-Badges je Datei und je Ordner, mit der Aufschlüsselung je Metrik beim Überfahren. Standardmäßig aus: mit explorerBadges.enabled einschalten.
• Seit dem letzten Lauf – ein rotes Dreieck auf jeder Zeile, die im vorherigen Lauf ausgeführt wurde und in diesem nicht, ein grünes für den umgekehrten Fall, mit Übersichtslineal und Trefferzahlen beim Überfahren.
• Bearbeitete Puffer – jede Markierung, jeder Hover und jede CodeLens wandert beim Bearbeiten mit dem Text mit und zieht sich von einer umgeschriebenen Zeile zurück, wo ein grauer Punkt sagt, warum.
• Inline-Trefferzahlen — hitCounts.inline schreibt ×12 hinter jede Zeile, auf der eine Anweisung beginnt, ×0 eingeschlossen: die Zahl, die schon immer beim Überfahren zu sehen war, ohne Überfahren. Toggle Inline Hit Counts schaltet sie um; das Statusleisten-Menü bietet sie als Anzeigen oder Ausblenden an, je nachdem, was gerade zutrifft.
• Problems-Einträge je Zeile — problems.perLine setzt eine Informations-Diagnose, mit einer Wellenlinie im Editor, auf jeden zusammenhängenden Block von Zeilen, die in einem geöffneten Dokument nie liefen (eine vierzigzeilige tote Funktion ist ein Eintrag, nicht vierzig), und als uncoveredAndPartial auf jede Zeile, deren Zweig nie genommen wurde. Die Einträge folgen ihren Zeilen beim Bearbeiten und verschwinden, wenn das Dokument geschlossen wird; der Eintrag je Datei hinter problems.enabled ist unverändert.
• Zeilenfärbung — lineHighlight legt eine durchscheinende Färbung hinter die Zeilen selbst, für das, was der Randstreifen markiert (uncovered, oder heatmap auch für die ausgeführten Zeilen). Eine eigene Einstellung, damit der Randstreifen sauber bleiben kann, während die Lücken gefärbt werden, oder umgekehrt.
• Übersichtslineal — overviewRuler entscheidet über den Streifen in der Bildlaufleiste unabhängig vom Randstreifen: follow (mit den Balken, wie bisher), uncovered (immer, der Randstreifen darf also aus sein, während die Bildlaufleiste die Lücken der Datei weiterhin abbildet) oder off.
• Welche Tracedatei eine Zeile abgedeckt hat — sind mehrere Berichte zusammengeführt, endet der Hover mit der Trefferzahl mit Abgedeckt von: und jedem Bericht, der diese Zeile abgedeckt hat, samt Suite-Name aus lcovs TN:; ein Klick auf eine Tracedatei-Zeile in der Ansicht Coverage hebt die von ihr beigesteuerten Zeilen in jedem offenen Editor hervor.

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

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

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

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

Editor-Gutter-Modi

editorGutter.mode entscheidet, was der eigene Gutter des Editors über die Coverage zeigt, zusätzlich zu den Befunden, die er immer zeigt. off (der Standard) ist nur diese. uncovered setzt einen Balken auf jede Zeile, die nie lief, und einen bernsteinfarbenen auf jede Zeile mit einem nie genommenen Zweig, und nichts auf abgedeckte Zeilen, sodass eine grüne Wand die drei roten nicht verdeckt. coverage fügt einen grünen Balken auf jeder abgedeckten Zeile hinzu, sodass die ganze Datei rot, bernsteinfarben und grün in den Farben der Farbskala erscheint. heatmap legt stattdessen einen warmen Farbton auf jede ausgeführte Zeile, umso heißer, je öfter sie lief — er zeigt, wie oft eine Zeile lief, nicht, ob sie abgedeckt ist, daher ist eine Datei mit 100% dort gelb bis braun, nie grün. Choose Editor Gutter Mode... wählt einen aus der Palette oder dem Statusleisten-Menü; die Modus-Schaltfläche rechts in der Statusleiste oder Alt+G schaltet mit einem Druck zum nächsten weiter (statusBar.showModeToggle blendet die Schaltfläche aus). Beide schreiben die Einstellung. Das Beispiel schaltet die Balken auf nicht abgedeckten Zeilen und die Inline-Zähler zusammen ein:

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

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

Die Heatmap ist relativ zur Datei. Der Farbton einer Zeile vergleicht ihren Zähler mit der heißesten Zeile derselben Datei, auf einer logarithmischen Skala, in fünf Stufen – so sind ein Schleifenrumpf, der tausendmal lief, und eine Funktion, die zweimal lief, beide sichtbar, statt dass das eine das andere überdeckt, und eine Datei, in der alles genau einmal lief, ist gleichmäßig warm statt gleichmäßig blass. In einem dunklen Design reicht die Farbskala von gedämpftem Oliv bis zu kräftigem Orange, in einem hellen Design von blassem Gelb bis Braun: In beiden Fällen bedeutet mehr Farbe mehr Ausführungen, und Rot bleibt den Zeilen vorbehalten, die nie ausgeführt wurden. lineHighlight: "heatmap" legt dieselben Farbtöne als Lasur hinter den Code, und hitCounts.inline schreibt den genauen Zähler hinter die Zeile.

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

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

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

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

Die Farben bestimmen Sie. colorScale.lowColor, midColor und highColor geben das Rot, Bernstein und Grün des Gutters, der Färbungen und jeder Prozentzahl vor; heatmap.colors und heatmap.colorsDark enthalten die fünf Farbtöne der Heatmap für ein helles und ein dunkles Design, von der Zeile, die am seltensten lief, bis zu der, die am häufigsten lief. Die Einstellungsseite zeigt das Ergebnis, bevor etwas gespeichert wird: unter Colour scale bleibt eine Vorschau sichtbar, während die Zeilen vorbeiscrollen — der Verlauf mit seinen zwei Stützpunkten, einige Prozentzahlen in ihren Farben und ein kleiner heller und ein kleiner dunkler Editor, gefärbt im Modus coverage und in der Heatmap —, und sie wird neu gezeichnet, sobald eine Farbe gewählt wird.

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

Der Teil einer Zeile, der nie ausgeführt wurde

Eine Zeile ist abgedeckt oder sie ist es nicht – und die Wahrheit liegt oft dazwischen: return x > hi ? hi : x; wurde ausgeführt, ihr hi-Arm jedoch nie. Ist lineHighlight eingeschaltet, wird der nie ausgeführte Teil einer ausgeführten Zeile im Editor eingefärbt, und zwar für jedes Format, das Spaltenbereiche enthält (llvm-cov, Istanbul, Go, dotnet-coverage) – dieselben Abschnitte, die auch der annotierte Quelltext markiert. Nur in Zeilen, die ausgeführt wurden: Eine Zeile, die nie ausgeführt wurde, ist bereits als Ganzes markiert. Ein C++-Template gilt dort als ausgeführt, wo irgendeine Instanziierung es ausgeführt hat; was jede einzelne Instanziierung getan hat, zeigt die Instanziierungsmetrik.

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

Welche Tests diese Zeile ausgeführt haben

Manche Berichte sagen nicht nur, dass eine Zeile ausgeführt wurde, sondern auch, welche Tests sie ausgeführt haben: coverage.py, geschrieben mit coverage json --show-contexts und dynamic_context = test_function in .coveragerc, OpenCover, erfasst mit -coverbytest, und eine lcov-Tracefile, geschrieben mit einem Abschnitt je Test (TN:), deren Abschnitte zu einem Datensatz mit einem Test je Zeile addiert werden. Zeigen Sie mit der Maus auf den Zeilenanfang, wo der Trefferzähler steht, und die Tests werden genannt — gekürzt auf Klasse und Methode, die ersten fünf namentlich, der Rest als Anzahl; die CodeLens der Funktion sagt, wie viele Tests sie ausgeführt haben. Show Tests That Ran This Line — die Befehlspalette, das Kontextmenü des Editors, in Visual Studio Tools → Coverage Studio oder Ctrl+Shift+U, T — listet sie auf, die fleißigsten zuerst, und öffnet den gewählten dort, wo er im Arbeitsbereich geschrieben steht. Ein dotnet test-Lauf kann nicht sagen, welcher Test was ausgeführt hat; setzen Sie testRun.perTest, und Run Tests with Coverage listet die Testklassen auf und führt sie eine nach der anderen aus, jeden Bericht mit seiner Klasse versehen, sodass der Hover, die Lens und der Befehl auch für .NET antworten können. Die Information wird pro Datei gehalten und übersteht daher das Zusammenführen mit einem Bericht, der nichts über Tests weiß.

{
  "fuciniCoverage.testRun.perTest": true
}

# .coveragerc
[run]
dynamic_context = test_function

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

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

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

Bestanden oder fehlgeschlagen, an den Markierungen

Eine abgedeckte Zeile sieht gleich aus, ob ihr Test bestanden hat oder nicht. Wo der Bericht sagt, welche Tests eine Zeile ausgeführt haben, und die Ergebnisdatei des Runners sagt, wie sie ausgegangen sind, erhält eine Zeile, die ein fehlgeschlagener Test ausgeführt hat, einen roten Balken an ihrem Anfang und einen Streifen im Übersichtslineal; ihr Hover nennt die fehlgeschlagenen Tests, und Show Tests That Ran This Line schreibt failed neben jeden. Ist ein Test rot, sieht man in dem Code nach, durch den er gelaufen ist. Die Ergebnisse werden bei jedem Laden aus dem Ordner jedes Berichts gelesen — jede .trx und die Namen, unter denen JUnit-Ergebnisse geschrieben werden (TEST-*.xml, junit*.xml, test-results*.xml) — und aus testResults.paths, als Pfade oder Globs relativ zum Ordner. Run Tests with Coverage verlangt von dotnet test eine test-results.trx neben dem Bericht, sodass bei eingeschaltetem testRun.perTest nichts einzurichten ist. testResults.enabled schaltet das Lesen ab.

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

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

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

Die Tests, die von einer Änderung betroffen sind

Ein vollständiger Lauf beantwortet langsam, was Run Tests Affected by My Changes… sofort beantwortet: Welche von allen Tests sind durch den Code gelaufen, den ich gerade bearbeitet habe? git wird nach dem Diff des Arbeitsverzeichnisses gegen testImpact.baseRef gefragt — standardmäßig HEAD, also das, was noch nicht committet ist; origin/main für alles, was der Branch ändert —, und die Tests, die eine geänderte Zeile ausgeführt haben, werden aufgelistet, zuerst der, der am meisten von der Änderung ausgeführt hat. Die Wahl eines Tests öffnet ihn. Wo die Berichte aus einem Lauf je Test stammen (testRun.perTest), führt der erste Eintrag nur diese Tests aus, jede Klasse in ihren eigenen Bericht, sodass die Berichte aller anderen Klassen bestehen bleiben und die Summen die der ganzen Suite bleiben. Ein Test, der nur Zeilen unterhalb einer Einfügung oder Entfernung ausgeführt hat, wird ebenfalls aufgelistet: Sein Bericht würde sonst die falschen Zeilen nennen.

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

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

Die wenigsten Tests, die noch jede Zeile ausführen

Show Minimal Test Set… beantwortet zwei Fragen aus denselben Zeilen je Test: welche wenigen Tests noch jede Zeile ausführen würden, die die Suite ausführt — für den schnellen Lauf vor einem Commit —, und welche Tests keine Zeile ausführen, die nicht schon ein anderer ausführt. Die ausgewählten Tests stehen zuerst, jeder mit den Zeilen, die er hinzufügt, und den Zeilen, die nur er ausführt; dann der Rest, jeder mit dem Vermerk, dass er nichts hinzufügt. Gewählt wird nach dem Greedy-Verfahren — der Test, der am meisten ausführt, dann der, der dazu am meisten hinzufügt —, die Auswahl liegt also nahe an der kleinsten Menge und ist jedes Mal dieselbe. Redundant nach Zeilen heißt nicht redundant nach dem, was ein Test prüft: Ein Test, der keine Zeile hinzufügt, kann trotzdem der einzige sein, der einen Wert prüft, den diese Zeilen liefern. Die Liste sagt, wo man hinsieht, wenn eine Suite ausgedünnt wird, nie, was zu löschen ist.

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

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

Diesen Test ausführen, mit Coverage

Setzen Sie den Cursor in einen Test und führen Sie Run This Test with Coverage aus — die Befehlspalette, das Kontextmenü des Editors, in Visual Studio Tools → Coverage Studio oder Ctrl+Shift+U, R —, und dieser Test allein läuft mit eingeschalteter Coverage: die Testmethode, in der der Cursor steht, oder die Testklasse bzw. der describe-Block, wenn er zwischen Methoden steht, oder die Datei, wenn er über jeder Klasse steht. Was unter dem Cursor liegt, wird aus dem Text gelesen, daher funktioniert es für C#, VB und F# ([Fact], [Test], [TestMethod] und dergleichen), JavaScript und TypeScript (it, test, describe) und Python (def test_…), welcher Sprachdienst auch immer installiert ist. Das Rezept des Ordners wird darauf eingeengt — dotnet test --filter "FullyQualifiedName~…", jest oder vitest <file> -t "…", eine pytest-Node-ID —, und was es geschrieben hat, wird geladen wie jeder Lauf; ein Runner, der sich nicht einengen lässt, sagt es, und Run Tests with Coverage führt sie alle aus.

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

Go und Rust. In einer Go-Datei läuft das func TestXxx unter dem Cursor (oder Fuzz…, Example…) für sich allein, in seinem eigenen Paket und unter seinem genauen Namen — go test ./pkg/calc -run "^TestTotal$" —, und außerhalb eines Tests läuft das Paket der Datei. In einer Rust-Datei läuft die #[test]-Funktion unter ihrem Pfad im Crate mit --exact; steht der Cursor in einem mod und in keinem Test, laufen die Tests dieses Moduls; ein Integrationstest unter tests/ läuft in seinem eigenen Binary (--test api). Ein Runner bekommt nur Dateien seiner eigenen Sprache: Eine TypeScript-Datei in einem Go-Ordner bekommt einen Satz, keinen leeren Lauf.

Coverage nach jedem Speichern

Mit eingeschaltetem testRun.onSave führt das Speichern einer Quelldatei kurz danach die Tests aus, die sie abdecken, mit Coverage, und die Randleiste folgt. Bei einer .NET-Projektmappe wird das Projekt der gespeicherten Datei über den .csproj-Graphen gefunden, und nur die Testprojekte, die darauf verweisen — direkt oder über andere Projekte —, werden ausgeführt, je ein dotnet test <project>; jeder andere Runner führt sein ganzes Rezept aus; eine Datei, die kein Projekt besitzt und kein Bericht misst, führt nichts aus. Mehrere Speichervorgänge nacheinander sind ein Lauf, und ein laufender Lauf wird nicht unterbrochen. Der Rest ist, wie Run Tests with Coverage es macht: das Terminal, der Output-Bereich, der geladene Bericht. Standardmäßig aus — es ist eine Gewohnheit, die man wählt, kein Standard, den man entdeckt.

{
  "fuciniCoverage.testRun.onSave": true
}

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

Die App selbst, mit Coverage

Ein Testlauf sagt, was die Tests erreichen. Was ein Mensch erreicht — der sich vor einem Release durch die Bildschirme klickt oder die Schritte eines Kunden nachspielt —, ist ebenfalls Coverage, und Run App with Coverage… erfasst sie. Die .NET-App des Ordners — eine Exe, eine WinExe, ein Web- oder Worker-Projekt, nie ein Testprojekt; eine Auswahl, wo es mehrere gibt — wird unter Microsofts dotnet-coverage in einer eigenen Konsole gestartet, damit sich in eine Konsolen-App tippen lässt, und läuft, bis Sie sie schließen. Was Sie durchlaufen haben, wird dann geladen wie jeder Lauf, und in einer Coverage-Sitzung wird es zu dem addiert, was die Tests ausgeführt haben. Wie die App geendet hat, wird dem Lauf nicht angelastet. Das Werkzeug muss einmal installiert werden: dotnet tool install --global dotnet-coverage.

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

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

Mutanten – und wo sie sitzen

Ein Mutationswerkzeug – PIT für Java, Stryker für JavaScript, C# und Scala, Mull für C und C++ – verändert Ihren Code in kleinen Schritten und lässt die Tests gegen jede Änderung laufen. Eine Änderung, die kein Test bemerkt, ist ein überlebender Mutant: Der Code wurde ausgeführt, und nichts hat geprüft, was er getan hat. Der Mutationsscore sagt, wie viele entdeckt wurden; seit 0.2026.83 sagt der Editor, wo die übrigen sitzen. Eine Zeile mit einem Mutanten trägt einen Hinweis am Zeilenende (⚑ 2 mutants survived), der geänderte Text ist unterstrichen, sofern der Bericht angibt, welcher Text es war (Stryker und Mull tun das), das Übersichtslineal erhält einen Streifen, und der Hover zeigt, was geändert wurde, wie viele Tests die Stelle ausgeführt haben und – bei den entdeckten Mutanten – welcher Test sie entdeckt hat.

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

Überlebt bedeutet: Tests haben den geänderten Code ausgeführt und alle bestanden. Ungetestet (im Bericht no coverage) bedeutet, dass überhaupt kein Test diesen Code ausführt – es konnte also nichts auffallen. Entdeckte Mutanten werden im Hover gezählt und nie markiert, und Mutanten, die nie ein fairer Test waren – etwa einer, der nicht kompilieren würde –, bleiben außerhalb des Scores. Der annotierte Quelltext hat unter jeder solchen Zeile eine eigene Zeile und eine Schaltfläche Next Mutant (U), und die HTML-Berichte haben einen Abschnitt Surviving Mutants, der zur Zeile verlinkt. Es muss nichts eingeschaltet werden, und ein Projekt ohne Mutationsbericht sieht nichts davon.

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

Würde ein Test es bemerken? Ein Mutationslauf am Cursor

Der Mutationslauf eines Projekts dauert eine Stunde; der einer einzelnen Funktion eine Minute. Run Mutation Tests Here führt diese Minute aus: Die Funktion, in der der Cursor steht — oder die markierten Zeilen, oder die Datei —, ist das, was der Mutations-Runner des Ordners mutieren soll, und sein Bericht wird neben der Coverage auf dem Bildschirm geladen, wo die überlebenden Mutanten markiert werden. Für C# ist es Stryker.NET (dotnet tool install --global dotnet-stryker), dem der Zeichenbereich und das Testprojekt genannt werden, das auf das Projekt der Datei verweist; für JavaScript und TypeScript StrykerJS, dem die Zeilen genannt werden; für Java PIT mit Maven, dem die Klasse genannt wird. Wie der Runner geendet hat, wird dem Lauf nicht angelastet: Ein Score unter seinem Schwellenwert ist ein Exit-Code und trotzdem ein Bericht. Hat ein Runner nichts geschrieben, wird das gesagt, zusammen mit dem, was er installiert braucht.

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

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

VS Codes eigene Test-Coverage-Ansicht

Mit eingeschaltetem testCoverage.publish (dem Standard) geht jeder geladene Lauf auch in die native Test-Coverage-Ansicht des Editors — das Coverage-Panel des Test Explorers, die Prozentzahlen je Datei, die er in den Explorer setzt, und den editoreigenen Schalter Show Inline Coverage — als Zeilen, Zweige und Funktionen, mit bei Bedarf geladenen Details, aus welcher Tracedatei auch immer sie stammen und ohne beteiligten Test-Adapter. Show in Test Coverage View veröffentlicht den aktiven Lauf und öffnet das Panel, was auch immer die Einstellung sagt; das Statusleisten-Menü bietet es hinter quickActions.showTestCoverage an. Ausgeschaltet erscheint überhaupt kein Eintrag Fucini Coverage im Test Explorer. Nennt eine Tracedatei ihre Tests (die TN:-Abschnitte von lcov), erscheint jeder Test unter Fucini Coverage im Test Explorer, und die Ansicht kann die Abdeckung einer Datei nach Test filtern.

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

Nicht abgedeckte Zeilen im Problems-Panel

Standardmäßig aus, weil es seiner Natur nach laut ist, und immer nur für die geöffneten Dokumente — ein Lauf mit zweitausend Dateien kann das Panel nicht fluten. Unabhängig von problems.enabled, das bei einem Eintrag je Datei bleibt:

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

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

9. Diff-Coverage

Beschränken Sie Dekorationen auf Zeilen, die sich gegenüber einer git-Basisreferenz geändert haben — ideal, um genau zu prüfen, was ein PR abgedeckt hat und was nicht:

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

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

Ein Gate für neuen Code

threshold.newCode ist ein eigenes Gate neben denen für den ganzen Lauf: der Mindestanteil der messbaren, gegenüber gitDiff.baseRef geänderten Zeilen, der gelaufen sein muss. Ein Projekt mit insgesamt 62% kann trotzdem verlangen, dass getestet ist, was heute geschrieben wird. Gezählt wird bei jedem Laden am ganzen Lauf, der auf dem Bildschirm bleibt — gitDiff.enabled ist das andere: die geänderten Zeilen anstelle des Laufs. Check Coverage Thresholds und die Compliance-Einträge im Problems-Panel melden sein Scheitern in einem eigenen Satz: New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran). Eine Änderung ohne messbare Zeile — Kommentare, ein README — lässt nichts scheitern.

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

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

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

Neuer Code nach Git-Tag, nach Autor, nach Datum

Neuer Code sind standardmäßig die Zeilen, die das Arbeitsverzeichnis gegenüber gitDiff.baseRef ändert — einem Branch, einem Commit oder einem Tag: "v1.4.0" ist alles seit diesem Release. Zwei Einstellungen fragen, was eine Ref nicht kann. gitDiff.author nimmt einen Teil eines Autorennamens, und neuer Code sind dann die Zeilen, die git diesem Autor zuschreibt; gitDiff.since nimmt ein Datum, und es sind die Zeilen, die an diesem Datum oder später zuletzt geändert wurden, über welchen Branch auch immer sie hereinkamen; beide zusammen: die Zeilen dieses Autors seit diesem Datum. Sie werden aus git blame gelesen, Datei für Datei — was ein großer Lauf bei jedem Laden spürt —, und treten für die Diff-Coverage und das Gate oben an die Stelle des Diffs. Eine noch nicht committete Zeile zählt in jedem Fall.

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

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

Indirekte Änderungen: was sich bewegt hat, obwohl es niemand angefasst hat

Ein Diff sagt, welche Zeilen sich geändert haben; zwei Läufe sagen, welche Zeilen nicht mehr oder neuerdings laufen. Einen Blick wert sind die Zeilen, bei denen beide nicht übereinstimmen: Code, den niemand bearbeitet hat und der nicht mehr läuft, weil ein Test gelöscht wurde, ein vorgelagerter Zweig jetzt früh zurückkehrt, eine Fixture sich geändert hat. Ein Review des Diffs kann sie nicht sehen — sie liegen per Definition außerhalb. Show Indirect Coverage Changes… listet sie je Datei auf, die Datei, die am meisten verloren hat, zuerst, und öffnet die gewählte an ihrer ersten solchen Zeile. Der Lauf wird gegen die CI-Baseline gehalten, wo baseline.report eine nennt — an ihr wird ein Pull Request gemessen —, und sonst gegen den Lauf davor; die Zeilen, die das Arbeitsverzeichnis gegenüber gitDiff.baseRef ändert, und alles unterhalb einer Stelle, an der diese Änderung die Zeilen der Datei verschiebt, bleiben außen vor.

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

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

10. Der Gesamtscore

Statt sechs Zahlen auszugeben, fasst die Erweiterung sie zu einem gewichteten harmonischen Mittel (WHM) zusammen. Für Metriken mit Prozentwerten pᵢ und Gewichten wᵢ:

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

Ein harmonisches Mittel wird von seinem kleinsten Term dominiert, sodass eine schwache Metrik nicht durch eine perfekte überdeckt werden kann — genau die Eigenschaft, die man von einer Sicherheitsschranke erwartet. Standardgewichte:

Setzen Sie ein Gewicht auf 0, um diese Metrik aus dem Score auszuschließen. Metriken, die in den Daten nicht vorhanden sind (z. B. MC/DC bei einem reinen lcov-Lauf), werden einfach weggelassen.

Objektcode und der Mutationsscore haben das Gewicht 0, bis Sie etwas anderes festlegen (whmWeights.objectCode, whmWeights.mutation). Die Objektcode-Abdeckung schließt die Anweisungsabdeckung ein; wer beide gewichtet, zählt also denselben Nachweis doppelt. Ein Mutationsscore ist überhaupt keine Abdeckung – eine Testsuite kann jede Zeile ausführen und nichts erkennen. Beide haben dennoch eine eigene Spalte und einen eigenen Schwellenwert.

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

Bedingungsabdeckung

a && b ist eine Entscheidung – zwei Zweige – und zwei Bedingungen mit vier Ausgängen. Eine Testsuite kann beide Zweige nehmen und b doch nie als falsch sehen: Die Zweigabdeckung ist vollständig, die Bedingungsabdeckung liegt bei drei von vier. Diese Stufe liegt in DO-178C und ISO 26262 zwischen Zweigabdeckung und MC/DC, und seit 0.2026.83 ist sie eine eigene Metrik, statt in den Zweigen aufzugehen: eine Zeile in den Karten der Statusleiste, eine Spalte in der Coverage-Ansicht, in den Berichten und den Exporten, ein Gewicht von 3 im Score (whmWeights.conditions) und eine Schranke (threshold.conditions; im Profil standard ohne Schranke, 100 unter safety).

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

Gelesen aus den condition-Probes von BullseyeCoverage, einem TRACE32-cond-Export und GCC 14, gebaut mit -fcondition-coverage. Ein Bericht, der Bedingungen nicht von Entscheidungen unterscheidet, hat weder eine solche Zeile noch Spalte noch ein Gewicht. Wenn Sie Bullseye oder TRACE32 verwenden: Bedingungen zählten bisher als Zweige; Ihr Zweigprozentsatz ändert sich daher mit dieser Version und mit dem neuen Gewicht auch Ihr Gesamtscore. Setzen Sie whmWeights.conditions auf 0, um den Score wie bisher zu erhalten.

GCC 14, Zeile für Zeile. -fcondition-coverage lässt gcov sagen, welches Ergebnis welcher Bedingung fehlt — Bedingung 1 nie wahr, Bedingung 0 mit keinem der beiden Ergebnisse —, und jede Bedingung wird auf ihrer Zeile markiert und im Hover genannt, aus gcovs JSON und aus seinem Textlisting (condition outcomes covered 3/6). Die Metrik steht dort, wo die anderen stehen: threshold.conditions ist ihr Gate und bleibt unbewertet, wo ein Lauf keinen solchen Wert hat, Copy Coverage Summary hat eine Spalte Conditions, badge.metric nimmt conditions, und das Suchfeld nimmt conditions < 80. Der Branch-Wert einer Funktion lässt die Ergebnisse ihrer Bedingungen aus, wie der der Datei und der des Laufs.

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

Komplexität und CRAP

Manche Berichte enthalten die zyklomatische Komplexität jeder Funktion: OpenCover (das Format, das Coverlet schreibt), JaCoCo, Clover und Cobertura. Wo das der Fall ist, berechnet die Erweiterung für die Funktion einen CRAP-Score – Change Risk Anti-Patterns – aus dieser Komplexität und aus der Abdeckung, die sie selbst gemessen hat:

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

Eine einfache, vollständig getestete Funktion erhält als Score ihre eigene Komplexität und nicht mehr; eine komplexe, kaum getestete landet im dreistelligen Bereich. Im C#-Beispiel des Demoprojekts hat Price() die Komplexität 22 und etwa 37 % abgedeckte Zeilen, was 142,2 ergibt, während Shipping() die Komplexität 12 hat und vollständig abgedeckt ist, was 12 ergibt. Die übliche Grenze ist 30: Eine Funktion, die sie erreicht oder überschreitet, wird im HTML-Bericht unter Riskiest Methods aufgeführt, die schlechteste zuerst.

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

Die Komplexität und der Score stehen im CodeLens der Funktion und neben der Funktion im annotierten Quelltext. Max CRAP ist der höchste Score aller Funktionen einer Datei – der schlechteste, kein Durchschnitt – und ist eine Spalte in der Coverage-Ansicht, im HTML-Bericht und in den CSV- und Markdown-Exporten. Er dient der Information: Er hat keinen Schwellenwert und kein Gewicht im Gesamtscore. Berichte, die keine Komplexität enthalten (lcov, gcov, Istanbul, coverage.py), haben keinen CRAP-Score und auch keine leere Spalte.

Seit 0.2026.83 gibt es ihn auch für C und C++. llvm-cov meldet keine Komplexität, daher wird sie aus den Zweigdaten gezählt, die der Bericht ohnehin enthält: die Bedingungen, die in der eigenen Datei der Funktion geschrieben stehen, plus eins – McCabes Definition, und das, was die Werkzeuge auf Quelltextebene für .NET und Java zählen. Bedingungen, die aus einem Makro einer anderen Datei stammen – jedes assert zum Beispiel –, werden nicht mitgezählt.

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

Risk hotspots, und welche Dateien gezeigt werden

Unter dem Baum der Coverage-Ansicht listet Risk hotspots die Funktionen, in denen komplexer Code auf wenig Coverage trifft, die schlimmste zuerst, und jede öffnet ihre Datei an der Funktion. Eine Funktion qualifiziert sich über den CRAP-Score — hotspots.crapThreshold, standardmäßig 30, der Wert, den die Autoren der Metrik vorgeschlagen haben — oder allein über die zyklomatische Komplexität, hotspots.complexityThreshold, standardmäßig aus; nur Berichte, die Komplexität enthalten (OpenCover, Cobertura aus Coverlet, JaCoCo, llvm-cov), haben welche. Community sieht die Anzahl und den schlechtesten Score; die Rangliste ist Pro. Neben der Sortierung sagt ein zweites Dropdown, welche Dateien der Baum zeigt — alle, Dateien mit Lücken, ungetestete Dateien oder die seit dem letzten Lauf geänderten Dateien; Ordner folgen ihren Dateien und behalten ihre eigenen Zahlen. Beides gibt es auch in Visual Studio, im Coverage-Fenster.

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

Namespaces, Klassen und Methoden

Für einen .NET-Bericht, der seine Klassen nennt — Cobertura und Coverlets coverage.cobertura.xml, OpenCover —, zeichnet ein drittes Dropdown, Folders / Namespaces, denselben Lauf als Namespaces, Klassen und Methoden: Die Zahl eines Namespace ist die Summe seiner Klassen, die einer Klasse die ihrer Methoden, genau wie die eines Ordners die seiner Dateien ist, mit derselben Sortierung und demselben Filter. Eine Methodenzeile öffnet die Datei an der Methode; eine in keinem Namespace deklarierte Klasse steht unter (no namespace). Die Wahl wird nach coverageView.perspective geschrieben; ein Lauf, der keine Klassennamen trägt, hat kein Dropdown und zeigt seine Ordner. In Visual Studio hat das Coverage-Fenster dasselbe Dropdown.

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

Den Baum durchsuchen

Unter den Schaltflächen und Dropdowns ein Suchfeld. Ein Wort behält die Zeilen, deren Name oder Pfad es enthält — jedes getippte Wort muss vorkommen; ein Vergleich behält die Zeilen, deren Zahl ihn besteht — < 80% auf den Wert, lines >= 90, branches = 0, functions != 100, mcdc < 50 —, und invoice < 80 verlangt beides. Methodenzeilen der Namespace-Perspektive und die Risk hotspots werden mit den Dateien durchsucht, sodass eine Funktion dort gefunden wird, wo der Lauf sie hat. Der Baum wird beim Tippen gefiltert, in der Seite, ohne Neuzeichnen; ein Ordner mit einem Treffer öffnet sich dafür und schließt sich wieder, wenn das Feld leer wird; Esc leert es. Dasselbe Feld, dieselbe Grammatik, in Visual Studio.

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

Der Baum folgt dem Editor

Die Datei, die Sie gerade ansehen, ist in der Coverage-Ansicht hervorgehoben, die Ordner darüber werden aufgeklappt, und ihre Zeile wird in den sichtbaren Bereich gescrollt — der Baum muss nicht mehr nach der Datei durchsucht werden, die schon geöffnet ist. Ansonsten behält der Baum seine Scrollposition, und nichts wird neu gezeichnet. coverageView.followActiveEditor, standardmäßig eingeschaltet, schaltet es für alle ab, die den Baum lieber dort lassen, wo sie ihn hingestellt haben.

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

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

11. Compliance-Prüfung

Das COMPLIANT-/NON-COMPLIANT-Urteil (angezeigt in der annotierten Quellansicht, im HTML-Bericht und in beiden Statusleisten-Hovers) wird durch metrikspezifische Schwellenwerte und einen Modus bestimmt:

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

Ein Schwellenwert von 0 schaltet diese Schranke aus, und eine Metrik, die der Bericht nicht enthält, wird nie beurteilt. Wofür ein Schwellenwert steht, den Sie nicht gesetzt haben, entscheidet das Profil weiter unten. Führen Sie Fucini Coverage: Check Coverage Thresholds aus, um bei Bedarf zu prüfen.

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

Schwellenwertprofile

threshold.profile legt fest, wofür ein Schwellenwert steht, den Sie nicht gesetzt haben. standard, der Standard seit 0.2026.82, ist das, woran sich ein gewöhnliches, nicht sicherheitsrelevantes Projekt messen lassen kann. safety bedeutet jede Schranke auf 100 – das, was ein Sicherheitsnachweis verlangt, und genau das, was bis 0.2026.81 ausgeliefert wurde.

Ein Schwellenwert, den Sie selbst gesetzt haben, hat Vorrang vor beiden Profilen. Das Beispiel setzt die Schranke für Zweige auf 90 und für alles andere auf 100; um nur einige Metriken auf 100 zu halten, bleiben Sie bei standard und setzen diese selbst. Eine Einschränkung ergibt sich aus der Funktionsweise von Einstellungen: Ein Wert, der dem ausgelieferten Standard entspricht, lässt sich nicht von einem fehlenden Wert unterscheiden. Unter safety zählt deshalb ein Schwellenwert, der genau mit seinem Standardwert angegeben ist – etwa 80 für Zeilen –, weiterhin als 100.

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

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

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

Wenn Sie sich auf die alten Standardwerte verlassen haben, werden Sie nach dem Update auf 0.2026.82 nachsichtiger beurteilt, bis Sie safety auswählen. Eine Installation, die bereits zuvor lief, wird einmalig darauf hingewiesen, mit einer Schaltfläche Keep 100% (safety), die das Profil in Ihre Benutzereinstellungen schreibt; bei einem gemeinsam genutzten Projekt tragen Sie es zusätzlich in die Arbeitsbereichseinstellungen ein, damit alle gleich beurteilt werden. Configure Coverage Compliance & Thresholds... zeigt das Profil oberhalb des Schwellenwertrasters, und die Live-Vorschau beurteilt mit den tatsächlich geltenden Schranken. In jeder Karte und jedem Bericht zeigt eine Metrik, deren Schranke ausgeschaltet ist, ihren Wert mit einem neutralen Strich statt mit einem Häkchen oder einem Kreuz.

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

11a. Objektcode-Coverage

Jede andere Metrik hier wird am Quelltext gemessen: ein Werkzeug instrumentiert Ihren Code, der instrumentierte Build läuft, und die Zähler sagen, welche Anweisungen, Zweige oder Bedingungen ausgeführt wurden. Objektcode-Coverage misst etwas anderes — wie viel des gebauten Binärprogramms tatsächlich ausgeführt wurde, gezählt in Instruktionsbytes, durch Beobachtung des Instruktionsstroms statt durch Instrumentierung des Quelltexts. Das ist wichtig, weil ein Compiler Code erzeugt, für den keine Zeile Ihres Quelltexts steht: Array-Grenzprüfungen, switch-Sprungtabellen, Register-Spills, Stack-Probes, Aufrufe von Laufzeit-Hilfsroutinen für Division oder Gleitkomma auf Kernen ohne die Instruktion. Sie ist außerdem die einzige Metrik hier, die die Frage deckt das Assembler ab? beantwortet — handgeschriebener Assembler wird nie instrumentiert, und ein quellbasiertes Werkzeug erreicht ihn nicht. DO-178C sagt ausdrücklich, warum: Auf Stufe A, wo ein Compiler oder Linker Code erzeugt, der nicht direkt auf Quelltextanweisungen zurückführbar ist, verlangt Ziel 6.4.4.2b zusätzliche Verifikation genau dieses erzeugten Codes.

Sie subsumiert die Anweisungsüberdeckung — jede ausgeführte Instruktion stammt aus einer Anweisung, also impliziert 100% Objektcode-Coverage 100% Anweisungsüberdeckung. Umgekehrt gilt das nicht, und genau diese Asymmetrie ist der Sinn der Messung. Daraus folgt zweierlei. Sie hat kein Gewicht im zusammengesetzten Score, denn zwei Maße derselben Ausführungen zu mitteln zählt denselben Nachweis doppelt; stattdessen wird sie über fuciniCoverage.threshold.objectCode geprüft — eine Anforderung statt eines Gewichts, genau wie die Norm es verlangt. Und die Lücke ist das Ergebnis: Ein Lauf mit 100% Zeilenüberdeckung und weniger als 100% Objektcode-Coverage hat genau den vom Compiler erzeugten Code gefunden, für den Ihr Quelltext nicht steht; die Compliance-Karte sagt deshalb 312 Bytes nie ausgeführt, bei 100% Zeilenüberdeckung, statt es als «94%» zu verstecken. Der umgekehrte Fall — ein ganzes Binärprogramm gilt als ausgeführt, sein Quelltext nicht — ist ein Widerspruch und kein niedriger Wert: fast immer ein veraltetes Tracefile auf einer Seite einer Zusammenführung oder Modulnamen, die nie zu Dateipfaden passten. Das wird als Befund gemeldet.

Objektcode-Coverage setzt voraus, dass das Binärprogramm dort läuft, wo seine Instruktionen beobachtet werden können. Es gibt drei Wege, und sie unterscheiden sich enorm im Aufwand. Nur der dritte liefert Objektcode-Coverage; die ersten beiden stehen hier, weil sie ein verwandtes Problem lösen, das oft das eigentlich lohnende ist.

1. Ein instrumentierter Build, der auf dem Target läuft. GCC-Cross-Compiler akzeptieren -fprofile-arcs -ftest-coverage, also funktioniert die Instrumentierung vom Arbeitsplatzrechner auch auf dem Target — nur hat ein Bare-Metal-System kein Dateisystem für die .gcda-Zähler und oft kein exit(), bei dem es sie schreiben könnte. Die Zähler liegen ohnehin im RAM, also besteht die Lösung darin, diesen Speicher auszulesen und die Dateien außerhalb des Targets zu rekonstruieren; embedded-gcov von NASA JPL (Apache-2.0) tut genau das, ohne Dateisystem, Betriebssystem oder Standard-C-Bibliothek. Das ergibt Anweisungs-, Zweig- und Funktionsüberdeckung eines Builds Ihres Cross-Compilers, für Ihren Befehlssatz, auf Ihrer Hardware — keine Objektcode-Coverage, und das gemessene Binärprogramm ist instrumentiert, also größer und langsamer als das ausgelieferte. Laden Sie das Ergebnis als LCOV, gcovr JSON, gcov JSON oder, bei einer Toolchain älter als GCC 9, als das Klartext-Listing .gcov.
2. Ein Befehlssatzsimulator. Führen Sie das echte Target-Binärprogramm in einem Simulator aus und leiten Sie die Coverage aus den ausgeführten Adressen ab: keine Hardware, keine Instrumentierung, keine Sonde — und weil er Instruktionen beobachtet, kann er echte Objektcode-Coverage liefern. Die Grenze ist die Modelltreue: Ein Simulator bildet den Kern gut und die Peripherie weniger gut ab, also behandeln Sie Gesamtsystem-Ergebnisse mit Misstrauen, sofern er Ihr Silizium nicht genau modelliert.
3. On-Chip-Trace und ein Debugger. Der zertifizierungstaugliche Weg und der einzige wirklich rückwirkungsfreie: Die Trace-Einheit des Kerns meldet den Instruktionsstrom an einen Debugger, der daraus Coverage macht. Nichts wird instrumentiert, die Codegröße ändert sich nicht und das Zeitverhalten bleibt unberührt — genau das macht das Ergebnis zu einem Nachweis über das tatsächlich ausgelieferte Binärprogramm. Prüfen Sie das Silizium, bevor Sie dafür Budget einplanen: Bei vielen Mikrocontrollerfamilien gibt es vollen Trace nur auf einer Emulations- oder Entwicklungsvariante mit großem Trace-Puffer und schnellem Trace-Port, während Seriengeräte eine reduzierte Trace-Einheit besitzen, deren Herstellerausweg eine Software-Trace ist, die den Code instrumentiert und Rechenzeit kostet — womit genau die Eigenschaft entfällt, derentwegen dieser Weg gewählt wurde.

Viele Embedded-Projekte messen Coverage, indem sie dieselben Quellen für den Entwicklungsrechner kompilieren und die Unit-Tests dort ausführen. Das ist schnell, braucht keine Hardware und ist für die meisten Teams die richtige Voreinstellung — aber man sollte sich klar machen, was dieser Nachweis eigentlich beschreibt: einen anderen Compiler, einen anderen Optimierer, einen anderen Befehlssatz und ein anderes Binärprogramm als das ausgelieferte. Für die meiste Software ist das ein akzeptabler und gut verstandener Kompromiss. Für Arbeiten, die nach IEC 61508, ISO 26262 oder DO-178C bewertet werden, ist dies der klassische Host-gegen-Target-Einwand, und die obigen Wege sind die klassischen Antworten darauf — der erste schließt ihn für Quell-Coverage, der dritte für Objektcode.

Derzeit ist der für Objektcode gelesene Export der von Lauterbach TRACE32's COVerage.EXPORT.ListModule mit metric="object"; laden Sie ihn wie jedes andere Tracefile. Die Metrik wird nur bei einer kostenpflichtigen Lizenz und während der Evaluierungsphase bewertet und geprüft. Eine Community-Installation bewertet sie nicht — wird aber informiert, wenn ein Tracefile sie enthält, denn ein Compliance-Urteil, das den stärksten Beweis in der Datei stillschweigend wegließe, wäre schlimmer als eines, das sagt, was es weggelassen hat.

12. Nicht-Code-Zeilen ausschließen

Ist excludeComments aktiviert (Standard), werden Anweisungen, die vollständig auf reinen Kommentar- oder Leerzeilen liegen, aus den Summen ausgeschlossen — dies neutralisiert auch eine bekannte Eigenheit von llvm-cov/gcov, bei der eine versprengte Trefferzahl auf einem Kommentar landet. Standardmarkierungen werden ebenfalls berücksichtigt:

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

Auch Präprozessor-Direktiven zählen als kein Code, in C, C++, Objective-C, CUDA und C#: eine Zeile, die mit # beginnt — #define, #include, #if —, und die Zeilen, auf die ein abschließender Backslash sie fortsetzt. gcov rechnet jede Verwendung eines Makros der Zeile zu, in der es definiert ist; so galt ein Header, dessen einzige gemeldete Zeile #define CHANNEL_COUNT (33U) war, als zu 100% abgedeckt, weil eine Schleife in der .c-Datei bis dorthin lief, und einer, dessen Konstante niemand verwendete, als zu 0%. Ein solcher Header hat jetzt nichts mehr zu messen und wird nicht aufgeführt.

Setzen Sie excluded.includeInTotals auf true, um ausgeschlossene Zeilen dennoch mitzuzählen.

Eine Datei oder einen Ordner herauslassen, aus dem Baum

Klicken Sie mit der rechten Maustaste auf eine Datei oder einen Ordner in der Coverage-Ansicht und wählen Sie Exclude from Coverage — es steht auch unter den Pfadaktionen der Zeile — oder führen Sie Exclude This File from Coverage auf der geöffneten Datei aus: Der arbeitsbereichsrelative Pfad der Datei oder das /** des Ordners wandert in fuciniCoverage.ignore in den Einstellungen des Ordners, einmal, und das Neuladen nimmt ihn aus jeder Summe und jeder Seite heraus; das Muster steht dort, um wieder entfernt zu werden. In Visual Studio haben das Menü der Zeile und Tools → Coverage Studio dieselben zwei, die dieselbe Einstellung in dieselbe Datei schreiben.

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

Attribute und Namespaces, für .NET

Zwei Einstellungen lesen aus der Quelle, was der Bericht nicht sagen kann. ignore.attributes — standardmäßig ExcludeFromCodeCoverage — schließt die Klasse, Methode oder Eigenschaft unter einem Attribut aus, das sie nennt, wie LCOV_EXCL_START/STOP es täten, welches Werkzeug auch immer den Bericht geschrieben hat: Coverlet beachtet das Attribut, OpenCover, dotCover und ein konvertiertes lcov nicht, und nun stimmen alle überein. Namen mit oder ohne das Suffix Attribute, mit oder ohne Namespace; fügen Sie GeneratedCode, Obsolete oder Ihre eigenen hinzu. ignore.namespaces lässt jede Datei heraus, deren Namespace-Deklaration auf ein Präfix passt, * als Platzhalter — Acme.Generated, Acme.*.Migrations, *Tests —, und der Output-Bereich nennt die Dateien, die er herausgenommen hat. Beide werden in demselben Durchgang gelesen, der die Kommentarmarker liest, in beiden Editionen.

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

Ausschließen aus dem Editor

Markieren Sie die Zeilen und nehmen Sie Exclude Selection from Coverage aus der Glühbirne, dem Kontextmenü des Editors oder der Befehlspalette — in Visual Studio die Glühbirne (Ctrl+.), das Kontextmenü des Codefensters, Tools → Coverage Studio oder Ctrl+Shift+U, X —, und der Ausschluss wird dorthin geschrieben, wo der Code ist: [ExcludeFromCodeCoverage] über einer C#-, VB- oder F#-Klasse, -Methode oder -Eigenschaft, mit dem kurzen Namen, wenn die Datei System.Diagnostics.CodeAnalysis bereits importiert, und voll qualifiziert, wenn nicht, sodass kein using hinzugefügt werden muss; LCOV_EXCL_LINE am Ende einer einzelnen Codezeile; LCOV_EXCL_START und LCOV_EXCL_STOP um mehrere, in der Einrückung der ersten Zeile — mit dem Kommentarzeichen der jeweiligen Sprache, //, #, ', -- oder ;. Ein Rückgängig-Schritt. Die Glühbirne bietet es auch auf einer Zeile an, die die Problems-Einträge als nicht abgedeckt markieren. Eine bereits markierte Zeile oder ein bereits attributiertes Element bleibt, wie es ist.

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

Nur Zweige, und die Marker von gcovr

Ein defensives else, ein default:, zu dem kein Wert gelangt, der Arm, den ein Compiler für eine Exception hinzufügt: Die Zeile läuft und soll zählen, und nur ihr Zweig kann nicht genommen werden. LCOV_EXCL_BR_LINE und LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP nehmen die Zweige auf ihren Zeilen aus der Zählung und lassen die Zeilen darin. LCOV_EXCL_EXCEPTION_BR_LINE und sein Bereich nehmen noch weniger heraus — nur die Arme, zu denen eine Exception führt, wo der Bericht sagt, welche das sind, wie es gcovs JSON tut. Jeder Marker wird auch unter den Präfixen von gcovr gelesen: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOVR_EXCL_BR_LINE, GCOV_EXCL_STOP und die übrigen bedeuten, was die LCOV_EXCL_-Marker bedeuten, sodass eine für gcovr geschriebene Quelle hier gleich gelesen wird, welches Werkzeug auch immer den Bericht erzeugt hat. Nicht gelesen: GCOVR_EXCL_FUNCTION — nichts auf dieser Zeile sagt, wo die Funktion endet.

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

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

Sagen, warum: begründete Ausschlüsse

Code aus der Zählung zu nehmen, ist eine Behauptung — „das lässt sich nicht testen“, „das ist eine Entwicklerhilfe“ —, und unter DO-178C, ISO 26262 oder IEC 61508 muss eine Behauptung, die die Zahl ändert, auf der ein Zertifikat beruht, niedergeschrieben und überprüfbar sein. Deshalb kann ein Ausschluss sagen, warum, und zwar dort, wo er geschrieben steht: der Text nach LCOV_EXCL_LINE oder LCOV_EXCL_START oder die Justification von [ExcludeFromCodeCoverage].

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

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

Die Begründungen werden bei jedem Laden gelesen, und das Log zählt sie. Export Coverage Report… schreibt die Liste — exclusions and their justifications, als Markdown oder CSV: die Datei, die Zeilen, wie der Ausschluss geschrieben wurde, und die Begründung oder none given. Eine Datei, in der nichts Messbares übrig bleibt, steht trotzdem in dieser Liste. Mit eingeschaltetem exclusions.requireReason ist ein Ausschluss ohne Begründung ein Befund: eine Warnung im Problems-Panel an seiner Zeile und ein Scheitern von Check Coverage Thresholds. Exclude Selection from Coverage fragt dann zuerst nach der Begründung und schreibt sie mit dem Marker oder als Justification des Attributs; wird die Frage abgebrochen oder leer gelassen, wird nichts ausgeschlossen.

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

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

12a. Beschreibt diese Coverage noch diese Datei?

12b. Nicht gemessen versus nicht abgedeckt

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

Header-Dateien sind der bekannte Fehlalarm in C: Sie gehören zur Erweiterungsfamilie des Laufs, und keine Tracedatei wird je eine nennen, denn für sich allein kompiliert sie zu nichts. fuciniCoverage.unmeasured.exclude lässt deshalb standardmäßig **/*.h, **/*.hpp, **/*.hh, **/*.inl und **/*.d.ts aus, in derselben Glob-Syntax wie fuciniCoverage.ignore; fügen Sie eine Plattformportierung hinzu, die hier nicht gebaut wird, oder generierte Stubs, und sie fallen aus der Liste, der Zählung und dem Statusleisten-Zustand heraus. Eine Datei, die ignore nennt, gilt ebenfalls nie als nicht gemessen — sie wegzulassen war ja der Zweck. threshold.unmeasuredFiles ist standardmäßig -1, was nicht prüft; 0 schlägt fehl, sobald irgendeine Datei von der Art des Laufs nie von einem Test geladen wurde, und gilt nur, solange unmeasured.mode auf list oder count steht.

13. HTML-Berichte

• Generate Full HTML Report — ein selbst gerenderter, mehrseitiger Bericht je Verzeichnis. Die Ausgabe erfolgt nach htmlReport.outputDir oder, falls nicht festgelegt, in den globalen Speicher der Erweiterung.
• Open Annotated Source — eine annotierte Ansicht einer einzelnen Datei. Verweisen Sie mit externalHtmlReport.dir auf ein vorab erstelltes llvm-cov show --format=html-Verzeichnis, um dessen Seiten statt des integrierten Renderers zu verwenden.
• Export Fucini JSON — das vollständige normalisierte Modell für eigene Tools.
• Export Coverage Report... — der Lauf als CSV (pro Datei oder pro Funktion), Markdown-Zusammenfassung, LCOV-Tracefile, Cobertura-XML, SARIF oder eigenständiges SVG-Badge für Ihre README. Auch über die Schaltfläche neben Generate Full HTML Report in der Ansicht „Abgedeckte Dateien“ erreichbar. Alles außer den CSVs ist verlustbehaftet — MC/DC, Regionen und Instanziierungen haben in LCOV, Cobertura oder SARIF keinen Platz —, daher bleiben Fucini JSON und die CSVs die Formate, die jede Metrik tragen.
• Copy Uncovered Lines — eine Markdown-Zusammenfassung jeder Lücke, bereit zum Einfügen in einen PR.

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

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

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

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

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

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

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

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

Kommentierter Quellcode vs. einfacher Quellcode

Open Annotated Source ersetzt den aktiven Tab durch eine farbcodierte Coverage-Webview für diese Datei, in derselben Spalte; Open Annotated Source to the Side tut dasselbe, jedoch in einer geteilten Ansicht, sodass Quelltext und kommentierte Ansicht nebeneinander stehen. Um stattdessen an Ort und Stelle hin- und herzuschalten — praktisch auf einem kleinen Bildschirm, auf dem eine Teilung jeden Bereich zu schmal macht — verwenden Sie Toggle Annotated Source: Dies wechselt den aktiven Tab zwischen beiden Ansichten und merkt sich, welche Sie gerade betrachten. Aus der kommentierten Ansicht heraus springt Show Source direkt zurück zum normalen Editor für diese Datei.

Welches HTML Sie tatsächlich sehen, hängt von externalHtmlReport.dir ab: Ist es gesetzt und existiert dort bereits eine zur aktiven Datei passende Seite (llvm-cov legt Seiten pro Datei als <Repo-Name>/<relativer-Pfad>.html an, sodass der Repo-Name-Ordner des Berichts nie konfiguriert werden muss), wird diese vom Toolchain generierte Seite anstelle des integrierten Renderers angezeigt — ihre lokalen Links/Stylesheets werden so umgeschrieben, dass sie innerhalb der Webview funktionieren, und sie enthält Details, die die integrierte Ansicht nicht wiedergibt (MC/DC-Erweiterungsansichten, Regionshervorhebung, Verzeichnis-Rollups). Keine passende Seite für diese Datei, oder die Einstellung leer gelassen? Dann wird stattdessen der integrierte Renderer verwendet. Die Erweiterung liest dieses Verzeichnis nur — sie schreibt niemals hinein.

Ein Coverage-Badge für die README

Generate Coverage Badge schreibt ein SVG im Stil von shields für den aktiven Lauf in den Arbeitsbereich — badge.outputPath, Standard coverage-badge.svg, relativ zum Arbeitsbereichsordner oder absolut, mit denselben Variablen wie jede andere Pfadeinstellung — und bietet an, es zu öffnen. Es ist eine einfache Datei in Ihrem Repository, also bettet eine README es ohne Dienst dahinter ein, ohne Umweg über shields.io, und es funktioniert auch in einem Repository ohne Netzanbindung:

![coverage](coverage-badge.svg)

badge.metric wählt, was das Badge zeigt: lines (beschriftet mit coverage), branches, mcdc oder weighted, dieselbe zusammengesetzte Bewertung, die die Statusleiste zeigt, beschriftet mit score. Ein Lauf ohne Daten für die gewählte Metrik bekommt ein graues n/a statt roter 0%. Die Farbe folgt Ihren eigenen colorScale.*-Stufen: lowColor unterhalb von lowThreshold, midColor bis highThreshold, highColor ab dort. Mit eingeschaltetem badge.autoUpdate wird das Badge nach jedem erfolgreichen Laden stillschweigend neu geschrieben, und der Ausgabekanal hält jeden Schreibvorgang als [FUCINI_BADGE] fest — standardmäßig aus, weil es bei jedem Laden in den Arbeitsbereich schreibt. Committen Sie das SVG mit dem Code, und das Bild auf der Repository-Seite folgt der Zahl im Editor.

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

14. Verlauf & Trends

Aktivieren Sie history.enabled, um Läufe lokal zu speichern (unter Beibehaltung von history.retention davon). Sie erhalten dann einen Trendpfeil (▲/▼) in der Statusleiste, das Trenddiagramm in der Coverage-Ansicht sowie zwei Vergleichsbefehle: Compare with Last Run und Compare Two History Runs, die jeweils ein Regressions-/Verbesserungs-Diff je Datei erzeugen.

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

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

Das Trenddiagramm

Unter der Symbolleiste der Coverage-Ansicht, mit zwei gespeicherten Läufen oder mehr, die Zeilen-Coverage des Verlaufs als Linie, vom ältesten zum neuesten, die neuesten dreißig: ein Punkt je Lauf, der beim Überfahren sein Datum und seinen Wert nennt, und daneben der letzte Wert mit einem Pfeil für die Richtung seit dem ersten. Die senkrechte Skala ist der Bereich der Läufe selbst, sodass ein Team bei 92–94% die Bewegung sieht statt einer flachen Linie unter 100. Beide Editionen zeichnen es aus demselben Verlauf.

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

Coverage-Sitzungen

Ein Testlauf deckt selten alles ab, was eine Änderung berührt hat: Die Unit-Tests liefen hier, die Integrationssuite dort, ein Gang durch die Oberfläche mit eingeschalteter Coverage woanders. Start Coverage Session macht aus den folgenden Ladevorgängen eine Summe — jeder Lauf wird Zeile für Zeile als Vereinigung zum vorigen addiert, eine Zeile, die einer von ihnen ausgeführt hat, ist abgedeckt, und die Zähler addieren sich —, sodass Randleiste, Baum und Wert zeigen, was sie alle zusammen erreicht haben. Der Lauf auf dem Bildschirm, falls es einen gibt, ist der erste der Sitzung. Eine Leiste über dem Baum sagt, wie viele Läufe seit wann, und beendet die Sitzung; End Coverage Session tut dasselbe, und das nächste Laden steht wieder für sich. In Visual Studio startet ein Eintrag unter Tools → Coverage Studio die Sitzung und beendet sie, angehakt, wieder.

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

Die CI-Baseline: Wo stehe ich gegenüber main?

Compare with Last Run beantwortet, was Ihre letzte Änderung bewirkt hat; vor einem Pull Request lautet die Frage, wo Sie gegenüber main stehen, und die Antwort liegt auf dem Build-Server. baseline.report nennt den Bericht, den der Build des main-Branches veröffentlicht, und jedes Laden wird dagegen gehalten: Die Karte der Statusleiste trägt das einzeilige Delta — vs CI baseline: 84.20% → 85.10% (+0.90%), 3 file(s) moved —, und Compare with CI Baseline listet die Dateien, die sich bewegt haben, Datei für Datei, in denselben Worten wie Compare with Last Run. In Visual Studio steht der Befehl unter Tools → Coverage Studio und ruft den Bericht ab oder liest ihn, wenn Sie danach fragen. Drei Arten, ihn zu nennen, in .vscode/settings.json:

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

Jedes Format, das der Leser kennt, genügt. Ein Pfad, den die CI relativ zu ihrem Checkout geschrieben hat — src/Billing/Invoice.cs, wie Coverlet ihn auf dem Runner schreibt —, wird vor dem Diff unter diesen Ordner gelegt, sodass er auf die Datei trifft, die der lokale Lauf aufgelöst hat; ein absoluter Pfad von einem anderen Rechner passt auf nichts, lassen Sie die Pipeline also relative Pfade schreiben. Eine Baseline, die sich nicht abrufen oder lesen lässt, ist eine Zeile im Output-Bereich, nie ein fehlgeschlagenes Laden.

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

Ein Artefakt ist ein Zip, und auch das wird gelesen. GitHub und GitLab geben ein Artefakt als Archiv heraus, was auch immer hineingelegt wurde. Nennen Sie den Bericht darin nach einem #: Der Eintrag wird über seinen Pfad oder dessen Ende gefunden; ohne # ist es die einzige Datei des Archivs oder seine einzige Datei, die wie ein Bericht aussieht, und wo es mehrere gibt, nennt der Output-Bereich sie. Dasselbe gilt für ein Zip, das Sie heruntergeladen haben (ci/artifact.zip#lcov.info), und, in VS Code, für eine URL in coverageFile.paths. Das Token geht an den Server, für den es gesetzt wurde, und nicht weiter: Der Weiterleitung zu dem Speicher, in dem das Archiv liegt, wird ohne das Token gefolgt.

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

14a. Für KI-Agenten: die Coverage auf dem Bildschirm

Ein Agent, der Tests schreibt, kann sie ausführen und eine Prozentzahl lesen. Was er von sich aus nicht kann, ist fragen, was der Editor weiß: welche Zeilen dieser Funktion nie liefen, welche Seite welches Zweigs, welche Tests eine Zeile ausführen, ob der Diff, den er gerade geschrieben hat, abgedeckt ist. Sechs Werkzeuge beantworten genau das, in Worten, nach denen ein Agent handeln kann, aus dem geladenen Lauf — dieselben Ausschlüsse, dasselbe Remapping, dieselben Zahlen wie auf dem Bildschirm. So sprechen ein Agent, der die Lücken einer Funktion abdecken soll, und ein Reviewer, der auf die Randleiste schaut, über dieselben Zeilen.

Der eigene Agent von VS Code hat sie als Werkzeuge, ohne dass etwas einzurichten wäre. Alle anderen Agenten — jeder Client, der MCP spricht, das Model Context Protocol — erreichen sie über einen Server, den der Editor betreibt, wenn mcp.enabled eingeschaltet ist, in VS Code wie in Visual Studio. Copy MCP Server Configuration legt den Eintrag für den Client in die Zwischenablage, so wie VS Code und Visual Studio ihn in einer mcp.json lesen; ein Client, der den äußeren Schlüssel mcpServers nennt, nimmt denselben Eintrag unter diesem Namen.

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

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

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

• Er ist aus, solange Sie ihn nicht einschalten, und er lauscht nur auf 127.0.0.1: Nichts außerhalb dieses Rechners erreicht ihn.
• Ein Aufruf muss Ihr Token tragen, das einmal erzeugt und für Sie aufbewahrt wird; ohne das Token lautet die Antwort 401. Die kopierte Konfiguration enthält das Token: Halten Sie sie aus dem Repository heraus.
• Ein Aufruf, den eine Webseite gesendet hat — er sagt es in seinem Origin —, wird abgewiesen, was auch immer er trägt.
• Er liest den geladenen Lauf und schreibt nichts. Der Testlauf wird genannt, nicht gestartet: Der Agent führt den Befehl in seinem eigenen Terminal aus.

Der Port ist mcp.port, 39217, wenn nichts anderes gesetzt ist. Wo dieser belegt ist — ein zweites Fenster, die andere Edition daneben —, wird der nächste freie verwendet, und die kopierte Konfiguration nennt den, der funktioniert. Der Output-Bereich sagt, wo der Server lauscht ([FUCINI_MCP]) und warum er es nicht konnte ([FUCINI_MCP_001]). Was ein Plan nicht enthält — die Namen von Tests, MC/DC-Details —, zählen die Werkzeuge, ohne es auszuschreiben, wie es der Hover tut.

15. Befehlsreferenz

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

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

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

16. Einstellungsreferenz

Die vollständige, kategorisierte Einstellungstabelle — jede Option mit ihrem Standardwert — finden Sie auf der Seite Features & Settings. Alle Schlüssel beginnen mit dem Präfix fuciniCoverage..

Erwähnenswert: fuciniCoverage.language legt die eigene Laufzeit-UI dieser Erweiterung (Statusleiste, Benachrichtigungen, Tooltips, Webviews) unabhängig von der Display Language von VS Code auf eine bestimmte Sprache fest — Standard ist auto, mit Bundles für alle 18 unterstützten Sprachen. Es ändert nicht die Einträge der Befehlspalette oder die Beschriftungen der Einstellungs-UI, die VS Code weiterhin aus seiner eigenen Display Language bezieht.

17. Fehlercodes

Diagnosemeldungen gehen an den Ausgabekanal Fucini Coverage (View → Output → Fucini Coverage), jede mit einem stabilen FUCINI_*-Code.

18. Datenschutz

Telemetrie wird über die window-bezogene Einstellung telemetry.enabled gesteuert. Standardmäßig ist sie aus. Die tägliche Zusammenfassung und die Entfernungsmeldung setzen zusätzlich voraus, dass VS Codes globales telemetry.telemetryLevel Telemetrie erlaubt; der Installations-Ping und einige kleine Ereignisse werden unabhängig davon gesendet, ebenso der Eintrag im Nutzungsregister einer Installation im Testzeitraum oder auf der kostenlosen Community-Stufe. Auf Community tauscht Unlock Full Features diese Telemetrie gegen jede Pro-Funktion, MC/DC eingeschlossen, für 30 Tage, einmal pro Gerät — schalten Sie sie wieder aus, gilt der Standardumfang von Community; eine bezahlte Lizenz ist in beiden Fällen unberührt. Was gesendet wird, steht in der Datenschutzerklärung.

Zwei Dinge sollten Sie kennen, weil Sie etwas mit ihnen tun können. Das erste ist Ihre Nutzungsregister-ID: In der Testphase und auf Community zeigt die Erweiterung sie unter Show License / Activation und am Ende von What Community Includes an, wo das Auswählen der Zeile sie kopiert und die Datenschutzerklärung öffnet. Das Register kennt Ihr Gerät über einen Hash und über sonst nichts, deshalb ist diese ID der einzige Weg, zu erfragen, was es zu Ihnen enthält, es löschen zu lassen oder ihm zu widersprechen — nennen Sie sie, und wir finden Ihre Zeile; ohne sie können wir es nicht. Das zweite ist der Installationseintrag: eine Zeile, geschrieben, wenn eine Installation zum ersten Mal meldet, und aufbewahrt statt nach 90 Tagen gelöscht, mit der Installationskennung, dem Tag, dem Ort, zu dem ihre Adresse aufgelöst wurde, den Versionen und dem Betriebssystem — nicht der Adresse und nichts über Ihren Code. Nur dadurch können wir sagen, wie viele Installationen es über die Jahre gab. Beides ist in der Datenschutzerklärung vollständig beschrieben, und beides wird auf Ihre Bitte hin gelöscht.

19. Evaluierung & Aktivierung

Fucini Coverage Studio wird als Evaluierungs-Vorabversion ausgeliefert. Beim ersten Start werden Sie gebeten, der Evaluierung zuzustimmen, und die Testphase beginnt — während einer 14-tägigen Testphase steht jede Funktion zur Verfügung, gerechnet ab der ersten Nutzung auf dieser Installation. Es gibt kein festes Datum, nach dem irgendetwas aufhört.

Ab Version 2.2026.2 beginnt die Testphase einer neuen Installation, sobald die Erweiterung den Lizenzserver einmal erreicht hat; bis dahin läuft sie auf der Community-Stufe und sagt das auch. In einem Entwicklungscontainer oder einem Codespace beginnt keine Testphase – ein Abonnementcode, ein Schlüssel oder der 7-Tage-Pass schaltet dort den vollen Umfang frei.

Wenn die Testphase endet, wird nichts gesperrt: Die Erweiterung fällt auf die kostenlose Community-Stufe zurück. Um den vollen Umfang zurückzubekommen, aktivieren Sie — die Aktivierung verbindet sich mit dem Lizenzserver und wendet den zurückgegebenen Schlüssel automatisch an, ohne E-Mail und ohne einen Schlüssel, den Sie von Hand übertragen müssten:

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

1. Führen Sie Fucini Coverage: Show License / Activation aus (nach Ablauf der Testphase bzw. des Schlüssels auch über die Statusleiste erreichbar) und klicken Sie auf Request License… (oder Request Renewed Key…, wenn Sie bereits aktiviert haben).
2. Bestätigen Sie die Anfrage. Der Schlüssel wird automatisch ausgestellt, und Ihre Kontaktdaten aus einer früheren Anfrage werden wiederverwendet statt erneut abgefragt.
3. Das war's. Der Aktivierungsschlüssel wird erzeugt und automatisch in fuciniCoverage.license.key geschrieben. Die Statusleiste wechselt kurz darauf von der Testphase zu einer aktivierten Lizenz.

Der manuelle Weg in einem Bild: Öffnen Sie das Lizenzpanel, wählen Sie Enter Key, fügen Sie den Schlüssel aus Ihrer E-Mail ein – und das Banner springt auf „Activated“.

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

{ "fuciniCoverage.license.key": "FCK1.…den gesamten Schlüssel einfügen…" }

Die kostenlose Community-Stufe: ein Wochenkontingent

Community hört nie auf, Coverage anzuzeigen. Die Gutter-Markierungen, das Übersichtslineal, Hover, CodeLens, die Coverage-Ansicht, der Watch-Modus, Diff-Coverage und der Verlauf werden überhaupt nicht gezählt, und das Laden eines Tracefiles per Befehl ist lediglich auf 25 am Tag begrenzt. Gemessen wird die Ausgabe: je fünf pro Woche für das Öffnen des HTML-Berichts, das Exportieren, den Vergleich zweier Läufe, die Prüfung der Schwellenwerte und die Anzeige des annotierten Quelltexts an Ort und Stelle.

Eine Woche gehört Ihnen, nicht dem Kalender: Sie beginnt mit der ersten Nutzung und endet sieben Tage später. Ist ein Kontingent aufgebraucht, nennt die Meldung die Aktion und den Tag, an dem es wieder verfügbar ist, und nach dieser einen Meldung weist nur noch die Statusleiste darauf hin. Fucini Coverage: What Community Includes listet jedes Kontingent auf, mit dem, was verbraucht ist, und dem Zeitpunkt der Zurücksetzung, noch bevor Sie je eines ausschöpfen.

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

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

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

Drei Details gehören zu den kostenpflichtigen Plänen, während ihre Befunde kostenlos bleiben: Community markiert jede Zeile mit überlebenden Mutanten und sagt, wie viele es sind, aber nicht, was jeder Mutant geändert hat; es sagt, wie viele Tests eine Zeile ausgeführt haben, aber nicht deren Namen; und es zeigt den Max CRAP eines Laufs, aber nicht die Rangliste Riskiest Methods.

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

Wenn Sie Community bereits genutzt haben, als das Wochenkontingent kam (0.2026.83), bleiben Ihre bisherigen Limits 30 Tage lang bestehen; Sie werden einmal darüber informiert, mit Datum. Die Zähler liegen auf Ihrem Rechner – im eigenen Speicher von VS Code und in ~/.fucini-coverage/, sodass ein neues VS-Code-Profil dieselbe Woche fortsetzt – und werden nirgendwohin gesendet.

Der 7-Tage-Pass

Noch nicht bereit für ein Abo? Ein 7-Tage-Pass ist alles aus Pro für eine Woche, einmal bezahlt: Nichts verlängert sich, und es gibt nichts zu kündigen. Kaufen Sie ihn auf der Preisseite (die Meldung an einem Community-Limit hat eine Schaltfläche dafür), und der Aktivierungscode kommt per E-Mail.

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

1. Führen Sie Fucini Coverage: Enter Subscription Code aus – den Befehl gibt es in der Community-Edition ebenso wie in Pro.
2. Wählen Sie Pro und fügen Sie den Code FCB1-… aus der E-Mail ein.
3. Das war's. Der Schlüssel wird für Sie ausgestellt und angewendet und funktioniert offline. Die Woche läuft ab der Zahlung, aktivieren Sie also gleich beim Kauf. Ist sie vorbei, kehrt die Erweiterung von selbst zu Community zurück und zeigt weiterhin Coverage an.

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

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

Auf einen neuen Rechner umziehen und Plätze verwalten

Ein Schlüssel ist an einen Rechner gebunden, ein neuer Rechner braucht also einen neuen — und Ihr Abonnement bezahlt nur so viele Rechner, wie es nennt. Geben Sie den alten selbst frei: melden Sie sich unter Abonnement verwalten an, suchen Sie den nicht mehr genutzten Platz, wählen Sie Free up und aktivieren Sie den neuen Rechner mit demselben Code. Beim Kauf von Pro wird Ihnen kein Passwort zugeschickt — Ihr Konto existiert, es hat nur noch keines. Nutzen Sie daher beim ersten Mal Passwort setzen oder zurücksetzen mit der Adresse, mit der Sie abonniert haben.

Bei Business und Enterprise laden Sie jede Kollegin und jeden Kollegen von derselben Seite aus per E-Mail ein. Jede Person erhält einen Aktivierungscode, der nur ihr gehört, und sobald sie ihn nutzt, erscheint ihre Adresse an ihrem Platz — verlässt jemand das Team, sehen Sie, welcher Platz seiner war, und geben ihn für die nächste Person frei. Eine Einladung belegt einen Platz ab dem Versand und verfällt nach 14 Tagen ungenutzt; ziehen Sie sie zurück, um den Platz sofort wiederzubekommen.

Vorabversionen testen

Neues erreicht fucini.software, bevor es den Marketplace erreicht, und Sie können darum bitten, es angeboten zu bekommen. Öffnen Sie die Coverage-Ansicht, klappen Sie den Lizenzbereich auf und drücken Sie Vorabversionen testen… — oder setzen Sie fuciniCoverage.update.preRelease. Von da an prüft die Erweiterung hier einen eigenen Vorab-Feed zusätzlich zum gewöhnlichen und bietet an, was neuer ist.

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

Vorabversionen sind getestet, aber es sind die Builds, bei denen wir am wenigsten sicher sind — Sie würden sich freiwillig melden, zu finden, was wir übersehen haben. Mit dem Beitritt erfahren wir, dass diese Installation im Kanal ist, damit wir wissen, wie viele Menschen testen, und sagen können, was sich geändert hat; treten Sie aus, bringt Sie die nächste stabile Version auf den gewohnten Weg zurück. Es gibt nicht immer eine Vorabversion, und beizutreten, wenn es keine gibt, kostet nichts: Die Erweiterung findet einen leeren Feed, sagt nichts dazu und bietet weiter stabile Versionen an, bis eine veröffentlicht wird.

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

20. Kontakt & Lizenz

Fragen, Fehlerberichte oder alternative Lizenzbedingungen — siehe die Kontaktseite oder schreiben Sie an info@fucini.consulting. Lizenziert unter MIT mit einer Bedingung zur Namensnennung in den Release Notes; siehe auch den Notice.

21. Auf der Kommandozeile

Der Reader läuft auch ohne Editor: npm install -g fucini-coverage, kostenlos, auf Windows, Linux, WSL und macOS. fucini-coverage check coverage/lcov.info --lines 80 ist das Gate, an dem eine Pipeline fehlschlägt; summary, export, report, badge und compare tun, was die gleichnamigen Befehle der Editoren tun, und mcp stellt die sechs Werkzeuge des Abschnitts oben einem Agenten auf einem Server bereit. Er liest fucini-coverage.json, die Einstellungsdatei, die die Visual-Studio-Edition liest, sodass die Schwellenwerte einmal gesetzt werden. fucini-coverage help <command> erklärt jeden; die vollständige Seite ist fucini-coverage auf npm.

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