Änderungsprotokoll

Behoben

• Der Ordner, in dem Sie den Befehl starten, entscheidet nicht darüber, was ein Bericht bedeutet. 2.2026.3 verankert die relativen Pfade eines Berichts in dem Verzeichnis, in dem dieser Bericht geschrieben wurde — aber nur für einen Befehl, der anderswo gestartet wurde. Aus der Wurzel des gemessenen Baums heraus ausgeführt, also dort, wo ein Coverage-Befehl üblicherweise ausgeführt wird, wurde ein relativer Pfad weiterhin von diesem Ordner beantwortet, und eine Datei, die llvm-cov bereits vollständig benannt hatte, wurde ein zweites Mal gezählt: ein Baum mit 5.258 Zeilen las sich als 5.836. Jetzt entscheiden nur noch --cwd und der Ort des Berichts selbst. Dieselbe Korrektur steckt in beiden Editoren, wo es der Ordner war, aus dem VS Code oder Visual Studio gestartet worden war.
• export --format json schrieb den Lauf über Ihre Einstellungen. Seine Datei war fucini-coverage.json — der Name, aus dem die Einstellungen gelesen werden — sodass der Export in einem gewöhnlich eingerichteten Ordner genau die Schwellenwerte zerstörte, nach denen er eben noch geurteilt hatte. Der Lauf wird nach coverage-run.json geschrieben, und export und badge verweigern ein --out, das die Einstellungsdatei benennt.
• --cwd nimmt einen Ordner, wie immer Sie ihn schreiben. Ein relativer — --cwd ., --cwd ../tree — wurde so übernommen, wie er getippt war, und nach den falschen Pfadregeln gelesen: unter Windows meldete er, eine halb POSIX, halb Windows geschriebene Einstellungsdatei sei nicht lesbar, und fand überhaupt keine Berichte. Auch ein abschließendes Trennzeichen gehört nicht mehr zum Ordner.
• Eine Option, die niemand erklärt hat, ist kein Bericht. summary -o out.json hielt -o für einen Bericht und meldete, es gebe diese Datei nicht. Nur -h und -v sind kurz; -- übergibt weiterhin eine Datei, deren Name mit einem Bindestrich beginnt, und eine vor dem Befehl getippte Option wird in der Fehlermeldung benannt, statt mit der ganzen Hilfe beantwortet zu werden.
• check --json sagt, was sein Exit-Code sagt. Ohne gesetzten Schwellenwert schrieb es "passed": false neben Exit-Code 0, und eine Pipeline, die das JSON statt des Exit-Codes las, ließ einen Lauf scheitern, den der Befehl bestanden hatte. passed ist der Exit-Code in einem Wort; configured sagt, dass es kein Gate gab. Ein leeres --lines "" wird abgelehnt, statt dieses Gate stillschweigend abzuschalten.
• Ein Vergleich legt die Baseline dorthin, wohin er den Lauf legt. pathRemap und die vom Bericht genannte Wurzel wurden auf den Lauf angewendet, nicht aber auf die Baseline: eine auf einem Build-Server geschriebene Baseline passte zu nichts, und der Vergleich meldete, nichts habe sich bewegt, neben einer Gesamtzahl, die sich sichtlich bewegt hatte.

Behoben

• Die relativen Pfade eines Berichts gehören zu dem Ordner, in dem dieser Bericht geschrieben wurde. llvm-cov schreibt den vollständigen Pfad einer Datei; gcovr schreibt ihn relativ zum Build-Ordner, in dem sein Bericht liegt. Mit beiden Berichten eines Baums führte summary jede Datei, die beide gemeinsam hatten, zweimal auf — je einmal mit den Zahlen jeder Engine — und addierte beide zur Summe, weil ein relativer Pfad keine Wurzel hatte, gegen die er auflösen konnte, und gegen den Ordner auflöste, in dem die Shell gerade stand. Ein Baum mit 5.258 Zeilen wurde als 5.836 gemeldet, wobei der Überschuss zu Dateien unter einem Pfad gehörte, der keine davon enthält. Jeder Bericht wird jetzt in seinem eigenen Ordner und den darüberliegenden verankert, bis zu dem Ordner, in dem der Befehl läuft, so wie es beide Editionen schon tun — damit die beiden als eine Menge Dateien zusammenfinden, ohne eine pathRemap-Regel pro Build-Verzeichnis.
• Eine Einstellungsdatei, die mit einer Byte-Order-Mark beginnt, wurde ebenfalls abgelehnt. Ein Editor unter Windows schreibt sie möglicherweise vor den Text; sie wird nicht länger für einen Teil des JSON gehalten.
• Ausgabe, die in einen früh abbrechenden Leser geleitet wird, endet still. summary nach head geleitet oder in PowerShells Select-Object -First starb mit einem unbehandelten EPIPE und einem Stacktrace. Dass der Leser die Pipe schließt, ist seine eigene Entscheidung und kein Fehler des Befehls: Er endet jetzt mit dem Exit-Code, den er erreicht hatte.

Behoben

• Eine Einstellungsdatei mit Mustern wurde abgelehnt. Stand **/*.lcov.info in einem Pfad von fuciniCoverage.coverageFile.paths und **/coverage.json im nächsten, endete jeder Befehl mit is not JSON: Was dazwischen lag, wurde für einen Kommentar gehalten. Die Datei wird jetzt so gelesen, wie die Editoren sie lesen – einschließlich eines Kommentars nach einem Wert und eines Kommas vor einer schließenden Klammer.

Hinzugefügt

• Der Reader auf der Kommandozeile, kostenlos. npm install -g fucini-coverage — derselbe Reader wie in den beiden Editionen, für die Orte, an denen kein Editor ist. Ein Paket, ein Verhalten auf Windows, Linux, WSL und macOS, Node 20 oder neuer.
• check, das Gate. Exit-Code 1 unter einem Schwellenwert für Zeilen, Zweige, Funktionen, MC/DC, Bedingungen, Regionen, Mutation oder die gewichtete Bewertung, aus den Einstellungen oder von der Kommandozeile; --new-code 80 --base-ref origin/main beurteilt die Zeilen, die ein Branch geändert hat, aus einem git diff, das das Werkzeug selbst ausführt; --require-reasons lässt eine Ausschlussmarkierung ohne Begründung durchfallen.
• summary, export, report, badge, compare. Die Summen und jede Datei; der Lauf als CSV pro Datei oder pro Funktion, Markdown, LCOV, Cobertura, SARIF, die Ausschlussliste, ein Badge oder Fucini JSON; der mehrseitige HTML-Bericht; das Badge, eingefärbt nach der Skala der Einstellungen; dieser Lauf gegen eine Baseline, Regressionen zuerst, mit --fail-on-regression für eine Pull-Request-Prüfung.
• mcp, für einen KI-Agenten. Die sechs Tools der Editionen, über dem Lauf bereitgestellt auf 127.0.0.1 hinter einem Token, mit dem Eintrag für die mcp.json des Clients ausgegeben.
• Die Einstellungsdatei der Visual-Studio-Edition. fucini-coverage.json neben dem Code, mit den fuciniCoverage.*-Schlüsseln der VS-Code-Einstellungen; .vscode/settings.json darunter. Berichte werden als Dateien, Ordner oder Muster genannt, ein .gz wird entpackt, und jeder Befehl dokumentiert sich selbst: fucini-coverage help <command>.

Geändert

• Die Testphase einer neuen Installation beginnt mit der ersten Antwort des Lizenzservers. Bis die Erweiterung fucini.software einmal erreicht hat, läuft sie auf der Community-Stufe und sagt, warum. Eine Installation, die bereits in ihrer Testphase ist oder eine Lizenz hat, bemerkt nichts.
• Keine Testphase in einem Entwicklungscontainer oder einem Codespace. Dort startet die Erweiterung auf der Community-Stufe; ein Abonnementcode, ein Schlüssel oder der 7-Tage-Pass schaltet alles frei.
• Das Nutzungsregister kennt eine Maschine an einem zweiten Hash, aus der eigenen Kennung des Betriebssystems. Gesendet wird nur der Hash; siehe die Datenschutzerklärung.

Behoben

• Kleine Korrekturen. Ein Wartungsrelease: kleine Korrekturen unter der Haube, und nichts, was ändert, was Sie sehen oder wie Sie es benutzen.

Behoben

• Kleine Korrekturen. Ein Wartungsrelease: kleine Korrekturen unter der Haube, und nichts, was ändert, was Sie sehen oder wie Sie es benutzen.

Hinzugefügt

• Die Coverage auf dem Bildschirm, für KI-Agenten. Ein Agent, der Tests schreibt, konnte sie ausführen und einen Prozentwert lesen; er konnte nicht fragen, was Visual Studio weiß. Sechs Tools beantworten das, in Worten, nach denen ein Agent handeln kann: coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta und test_run_command. Ein Agent, der MCP spricht, erreicht sie über einen Server, den Visual Studio betreibt, wenn fuciniCoverage.mcp.enabled eingeschaltet ist — standardmäßig aus, nur auf 127.0.0.1, hinter einem eigenen Token und für Webseiten verschlossen. Copy MCP Server Configuration legt den Eintrag für den Client in die Zwischenablage.
• Dieselben Zahlen wie auf dem Bildschirm. Die Tools antworten aus dem Lauf, der geladen ist — dieselben Ausschlüsse, dasselbe Remapping —, sodass ein Agent, der die Lücken einer Funktion abdecken soll, und ein Reviewer, der auf den Rand schaut, über dieselben Zeilen sprechen.

Geändert

• Der Plan eines Schlüssels entscheidet in Visual Studio, was er in VS Code entscheidet. Ein Plan, der eine Funktion auslässt — MC/DC, den HTML-Bericht, die Namen der Tests, die eine Zeile ausgeführt haben —, ließ sie in VS Code aus und hier nicht. Beide Editionen lesen jetzt dieselbe Tabelle: Eine Funktion, die der Plan nicht enthält, wird zurückgehalten, und ihr Befehl sagt es.
• Die Mindestversion, die der Lizenzserver verlangt, gilt auch hier. Beide Editionen tragen ab 2.2026.0 dieselbe Version, sodass ein Build, der älter als diese Mindestversion ist, um ein Update bittet, wie es die VS-Code-Edition tut.

Hinzugefügt

• Die Coverage auf dem Bildschirm, für KI-Agenten. Ein Agent, der Tests schreibt, konnte sie ausführen und einen Prozentwert lesen; er konnte nicht fragen, was der Editor weiß. Sechs Tools beantworten das, in Worten, nach denen ein Agent handeln kann: coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta und test_run_command. Der eigene Agent von VS Code hat sie als Language-Model-Tools, ohne dass etwas einzurichten wäre. Jeder andere Agent, der MCP spricht, erreicht sie über einen Server, den die Erweiterung betreibt, wenn fuciniCoverage.mcp.enabled eingeschaltet ist — standardmäßig aus, nur auf 127.0.0.1, hinter einem eigenen Token und für Webseiten verschlossen. Copy MCP Server Configuration legt den Eintrag für den Client in die Zwischenablage.
• Dieselben Zahlen wie auf dem Bildschirm. Die Tools antworten aus dem Lauf, der geladen ist — dieselben Ausschlüsse, dasselbe Remapping —, sodass ein Agent, der die Lücken einer Funktion abdecken soll, und ein Reviewer, der auf den Rand schaut, über dieselben Zeilen sprechen.

Behoben

• Eine Datei, die zwei Engines gemessen haben, ist eine Datei. llvm-cov schreibt den vollständigen Pfad einer Datei; gcovr schreibt ihn relativ zum Build-Ordner, in dem sein Bericht liegt. Ein relativer Pfad wird im Verzeichnis des Berichts und den Ordnern darüber verankert — davor fragte der Resolver jedoch, ob der Pfad so, wie er dasteht, existiert, und diese Frage wird aus dem Ordner heraus beantwortet, in dem Visual Studio selbst gestartet wurde. Enthielt dieser Ordner die Datei, blieb der Pfad relativ: die Datei hatte zwei Namen, erschien zweimal im Coverage-Fenster und wurde zweimal in die Summen gezählt. Ein Baum mit 5.258 Zeilen las sich als 5.836. Ein Pfad, der keinen eigenen Ort benennt, wird gar nicht mehr erfragt; er wird dort verankert, wo der Bericht geschrieben wurde, und die Zeile sagt es.

Behoben

• Eine Datei, die zwei Engines gemessen haben, ist eine Datei. llvm-cov schreibt den vollständigen Pfad einer Datei; gcovr schreibt ihn relativ zum Build-Ordner, in dem sein Bericht liegt. Ein relativer Pfad wird im Verzeichnis des Berichts und den Ordnern darüber verankert — davor fragte der Resolver jedoch, ob der Pfad so, wie er dasteht, existiert, und diese Frage wird aus dem Ordner heraus beantwortet, in dem der Extension Host gestartet wurde, nach code . also aus Ihrem Projektstamm. Der Pfad blieb dann relativ: die Datei hatte zwei Namen, erschien zweimal in der Coverage-Ansicht und wurde zweimal in die Summen gezählt. Ein Baum mit 5.258 Zeilen las sich als 5.836. Ein Pfad, der keinen eigenen Ort benennt, wird gar nicht mehr erfragt; er wird dort verankert, wo der Bericht geschrieben wurde, und die Zeile sagt es.
• Der gewählte Gutter-Modus gilt für die Sitzung, und Ihre Einstellungen bleiben, wie Sie sie geschrieben haben. Ein Modus, der über die Statusleiste, die Auswahl oder Toggle Coverage Painting gewählt wurde, wurde in settings.json geschrieben — eine Datei, die in vielen Projekten unter Versionskontrolle steht und hier von einer Schaltfläche umgeschrieben wurde, die zweimal pro Minute gedrückt werden soll. Die Wahl gilt jetzt für die Sitzung, und ein Modus, den Sie in Ihre Einstellungen geschrieben haben, gewinnt weiterhin, wenn das Fenster geöffnet wird.

Hinzugefügt

• Run Mutation Tests Here. Coverage sagt, dass eine Zeile gelaufen ist; ein Mutationswerkzeug sagt, ob ein Test merken würde, dass sie falsch ist. Die Funktion, in der der Cursor steht — oder die markierten Zeilen, oder die Datei —, ist das, was der Runner des Ordners mutieren soll, und sein Bericht wird neben der Coverage auf dem Bildschirm geladen: Stryker.NET für C#, StrykerJS für JavaScript und TypeScript, PIT mit Maven für Java. Der Mutationslauf eines Projekts dauert eine Stunde; der einer Funktion eine Minute.

Hinzugefügt

• Run Mutation Tests Here. Coverage sagt, dass eine Zeile gelaufen ist; ein Mutationswerkzeug sagt, ob ein Test merken würde, dass sie falsch ist. Die Funktion, in der der Cursor steht — oder die markierten Zeilen, oder die Datei —, ist das, was der Runner des Ordners mutieren soll, und sein Bericht wird neben der Coverage auf dem Bildschirm geladen: Stryker.NET für C#, StrykerJS für JavaScript und TypeScript, PIT mit Maven für Java. Der Mutationslauf eines Projekts dauert eine Stunde; der einer Funktion eine Minute.

Hinzugefügt

• Run App with Coverage… misst, was ein Mensch erreicht, nicht nur, was die Tests tun: Die .NET-Anwendung des Ordners wird unter Microsofts dotnet-coverage gestartet, in einer eigenen Konsole, und läuft, bis sie geschlossen wird. Was dabei durchlaufen wurde, wird dann wie jeder Lauf geladen und in einer Coverage-Sitzung zu dem addiert, was die Tests ausgeführt haben. Benötigt dotnet tool install --global dotnet-coverage.

Hinzugefügt

• Run App with Coverage… misst, was ein Mensch erreicht, nicht nur, was die Tests tun: Die .NET-Anwendung des Ordners wird unter Microsofts dotnet-coverage gestartet, in einer eigenen Konsole, und läuft, bis sie geschlossen wird. Was dabei durchlaufen wurde, wird dann wie jeder Lauf geladen und in einer Coverage-Sitzung zu dem addiert, was die Tests ausgeführt haben. Benötigt dotnet tool install --global dotnet-coverage.

Hinzugefügt

• Eine CI-Baseline aus einem Zip-Artefakt. GitHub und GitLab veröffentlichen ein Artefakt als Archiv. Wo baseline.report eines nennt — eine URL oder ein Zip auf der Festplatte —, wird es geöffnet und der Bericht darin behalten: der Eintrag, der nach dem # genannt ist (ci/artifact.zip#coverage/lcov.info), sonst die einzige Datei des Archivs, sonst seine einzige Datei, die wie ein Bericht aussieht.

Hinzugefügt

• Zip-Artefakte von GitHub und GitLab. CI veröffentlicht ein Artefakt, und ein Artefakt ist ein Archiv. Ein abgerufenes Zip wird jetzt geöffnet und der Bericht darin behalten — der Eintrag, der nach dem # der URL genannt ist (…/zip#coverage/lcov.info), sonst die einzige Datei des Archivs, sonst seine einzige Datei, die wie ein Bericht aussieht. Für eine URL in coverageFile.paths, für baseline.report und für eine Baseline, die ein Zip auf der Festplatte ist.

Behoben

• Die Dateien einer Cobertura-Baseline wurden unter dem eigenen <source> des Berichts nicht gefunden. Der Vergleich sagte 0 file(s) moved neben einer Summe, die sich bewegt hatte. Die Wurzel, die der Bericht nennt, wird jetzt verwendet, wie bei einem Bericht, der geladen wird.

Hinzugefügt

• Neuer Code nach Autor und nach Datum. Neuer Code waren die gegenüber einer Git-Ref geänderten Zeilen. Zwei Einstellungen fragen, was eine Ref nicht kann: fuciniCoverage.gitDiff.author — die Zeilen, die eine Person geschrieben hat — und fuciniCoverage.gitDiff.since — die Zeilen, die seit einem Tag geschrieben wurden. Beide werden aus git blame gelesen und gelten für die Diff-Coverage und für die Schwelle für neuen Code.

Hinzugefügt

• Neuer Code nach Autor und nach Datum. Neuer Code waren die gegenüber einer Git-Ref geänderten Zeilen. Zwei Einstellungen fragen, was eine Ref nicht kann: fuciniCoverage.gitDiff.author — die Zeilen, die eine Person geschrieben hat — und fuciniCoverage.gitDiff.since — die Zeilen, die seit einem Tag geschrieben wurden. Beide werden aus git blame gelesen und gelten für die Diff-Coverage und für die Schwelle für neuen Code.

Hinzugefügt

• Run This Test with Coverage liest Go und Rust. In einer Go-Datei läuft das func TestXxx am Cursor allein, in seinem eigenen Paket und über seinen genauen Namen — go test ./pkg/calc -run "^TestTotal$". In einer Rust-Datei läuft die #[test]-Funktion über ihren Pfad im Crate, --exact; in einem mod die Tests dieses Moduls; ein Integrationstest unter tests/ in seinem eigenen Binary.

Hinzugefügt

• Run This Test with Coverage liest Go und Rust. In einer Go-Datei läuft das func TestXxx am Cursor allein, in seinem eigenen Paket und über seinen genauen Namen — go test ./pkg/calc -run "^TestTotal$". In einer Rust-Datei läuft die #[test]-Funktion über ihren Pfad im Crate, --exact; in einem mod die Tests dieses Moduls; ein Integrationstest unter tests/ in seinem eigenen Binary.

Hinzugefügt

• Die Bedingungsabdeckung von GCC 14, Zeile für Zeile. -fcondition-coverage wurde als zwei Zählungen je Datei gelesen; jede Bedingung wird jetzt an ihrer Zeile markiert und im Hover genannt — Bedingung 1 nie wahr, Bedingung 0 weder wahr noch falsch — aus dem JSON von gcov und aus seinem Textlisting. threshold.conditions setzt die Schwelle dafür, Copy Coverage Summary hat eine Spalte Conditions, badge.metric nimmt conditions an, und die Suche nimmt conditions < 80 an.

Behoben

• Der Branch-Wert einer Funktion zählte auch die Ausgänge ihrer Bedingungen mit. branches 8/12, wo das Werkzeug 4 von 6 sagte. Bedingungen bleiben dort außen vor, wie in den Werten der Datei und des Laufs.

Hinzugefügt

• Die Bedingungsabdeckung von GCC 14, Zeile für Zeile. -fcondition-coverage wurde als zwei Zählungen je Datei gelesen; jede Bedingung wird jetzt an ihrer Zeile markiert und im Hover genannt — Bedingung 1 nie wahr, Bedingung 0 weder wahr noch falsch — aus dem JSON von gcov und aus seinem Textlisting. threshold.conditions setzt die Schwelle dafür, Copy Coverage Summary hat eine Spalte Conditions, badge.metric nimmt conditions an, und die Suche nimmt conditions < 80 an.

Behoben

• Der Branch-Wert einer Funktion zählte auch die Ausgänge ihrer Bedingungen mit. branches 8/12, wo das Werkzeug 4 von 6 sagte. Bedingungen bleiben dort außen vor, wie in den Werten der Datei und des Laufs.

Hinzugefügt

• Die Coverage-Ansicht folgt dem Editor. Die Datei, die Sie gerade ansehen, wird im Baum hervorgehoben, die Ordner darüber werden geöffnet, und ihre Zeile wird in den sichtbaren Bereich gescrollt. fuciniCoverage.coverageView.followActiveEditor schaltet es ab.

Hinzugefügt

• Die Coverage-Ansicht folgt dem Editor. Die Datei, die Sie gerade ansehen, wird im Baum hervorgehoben, die Ordner darüber werden geöffnet, und ihre Zeile wird in den sichtbaren Bereich gescrollt. fuciniCoverage.coverageView.followActiveEditor schaltet es ab.

Hinzugefügt

• Ausschlussmarkierungen nur für Branches, und die von gcovr. LCOV_EXCL_BR_LINE und LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP nehmen die Branches auf ihren Zeilen aus der Zählung und lassen die Zeilen darin; LCOV_EXCL_EXCEPTION_BR_LINE nimmt nur die Zweige heraus, die eine Exception erreicht. Jede Markierung wird auch unter den Präfixen von gcovr gelesen: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE und die übrigen.

Behoben

• Ein .NET-Bericht zeigte keine Branch-Coverage. Coverlet und dotnet-coverage schreiben das Attribut branch einer Cobertura-Zeile als True, und nur das kleingeschriebene true wurde gelesen — sodass jede Entscheidung in einem solchen Bericht wegfiel. Beide Schreibweisen werden jetzt gelesen. Zahlen bewegen sich: Die Branch-Coverage eines .NET-Projekts erscheint, wo es keine gab, und mit ihr sein Score.
• Ein aus mehreren Bäumen zusammengeführter Cobertura-Bericht fand nur die Dateien des ersten Baums. Ein solcher Bericht nennt ein <source> je Baum; jedes wird jetzt versucht, in der Reihenfolge des Berichts.

Hinzugefügt

• Ausschlussmarkierungen nur für Branches, und die von gcovr. LCOV_EXCL_BR_LINE und LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP nehmen die Branches auf ihren Zeilen aus der Zählung und lassen die Zeilen darin; LCOV_EXCL_EXCEPTION_BR_LINE nimmt nur die Zweige heraus, die eine Exception erreicht. Jede Markierung wird auch unter den Präfixen von gcovr gelesen: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE und die übrigen.

Behoben

• Ein .NET-Bericht zeigte keine Branch-Coverage. Coverlet und dotnet-coverage schreiben das Attribut branch einer Cobertura-Zeile als True, und nur das kleingeschriebene true wurde gelesen — sodass jede Entscheidung in einem solchen Bericht wegfiel. Beide Schreibweisen werden jetzt gelesen. Zahlen bewegen sich: Die Branch-Coverage eines .NET-Projekts erscheint, wo es keine gab, und mit ihr sein Score.
• Ein aus mehreren Bäumen zusammengeführter Cobertura-Bericht fand nur die Dateien des ersten Baums. Ein solcher Bericht nennt ein <source> je Baum; jedes wird jetzt versucht, in der Reihenfolge des Berichts.

Hinzugefügt

• Show Minimal Test Set… findet die wenigsten Tests, die noch jede Zeile ausführen, die die Suite ausführt, und listet darunter die Tests auf, die keine eigene Zeile beitragen. Für den schnellen Lauf vor einem Commit und für alle, die die Suite ausdünnen — mit dem Hinweis, dass redundant nach Zeilen nicht redundant nach dem ist, was ein Test prüft.

Hinzugefügt

• Show Minimal Test Set… findet die wenigsten Tests, die noch jede Zeile ausführen, die die Suite ausführt, und listet darunter die Tests auf, die keine eigene Zeile beitragen. Für den schnellen Lauf vor einem Commit und für alle, die die Suite ausdünnen — mit dem Hinweis, dass redundant nach Zeilen nicht redundant nach dem ist, was ein Test prüft.

Hinzugefügt

• Begründete Ausschlüsse. Code, der dort, wo er geschrieben steht, aus der Zählung genommen wird, kann sagen, warum — // LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] —, und die Gründe werden berichtet: Export Coverage Report… listet die Ausschlüsse und ihre Begründungen als Markdown und als CSV auf. Mit fuciniCoverage.exclusions.requireReason ist ein Ausschluss, der keinen Grund nennt, eine Warnung an seiner Zeile und lässt Check Coverage Thresholds fehlschlagen.

Hinzugefügt

• Begründete Ausschlüsse. Code, der dort, wo er geschrieben steht, aus der Zählung genommen wird, kann sagen, warum — // LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] —, und die Gründe werden berichtet: Export Coverage Report… listet die Ausschlüsse und ihre Begründungen als Markdown und als CSV auf. Mit fuciniCoverage.exclusions.requireReason ist ein Ausschluss, der keinen Grund nennt, eine Warnung an seiner Zeile und lässt Check Coverage Thresholds fehlschlagen.

Hinzugefügt

• Eine Schwelle für neuen Code, neben den Schwellen für den ganzen Lauf. fuciniCoverage.threshold.newCode ist die geringste Zeilenabdeckung, in Prozent, der gegenüber gitDiff.baseRef geänderten Zeilen. Check Coverage Thresholds lässt sie in einem eigenen Satz durchfallen — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) —, und der ganze Lauf bleibt auf dem Bildschirm.
• Show Indirect Coverage Changes… listet die Zeilen auf, deren Coverage sich bewegt hat, obwohl niemand sie bearbeitet hat — Code, der nicht mehr läuft, weil ein Test weggefallen ist oder weil ein Branch weiter oben jetzt früh zurückkehrt. Gegen die CI-Baseline, wo baseline.report eine nennt, sonst gegen den Lauf davor.

Hinzugefügt

• Eine Schwelle für neuen Code, neben den Schwellen für den ganzen Lauf. fuciniCoverage.threshold.newCode ist die geringste Zeilenabdeckung, in Prozent, der gegenüber gitDiff.baseRef geänderten Zeilen. Check Coverage Thresholds lässt sie in einem eigenen Satz durchfallen — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) —, und der ganze Lauf bleibt auf dem Bildschirm.
• Show Indirect Coverage Changes… listet die Zeilen auf, deren Coverage sich bewegt hat, obwohl niemand sie bearbeitet hat — Code, der nicht mehr läuft, weil ein Test weggefallen ist oder weil ein Branch weiter oben jetzt früh zurückkehrt. Gegen die CI-Baseline, wo baseline.report eine nennt, sonst gegen den Lauf davor.

Hinzugefügt

• Run Tests Affected by My Changes… listet die Tests auf, die eine Zeile ausgeführt haben, die der Arbeitsbaum gegenüber fuciniCoverage.testImpact.baseRef (standardmäßig HEAD) ändert, zuerst den, 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.

Behoben

• testRun.skipWhenTestsFail gilt über den Lauf hinaus. Die Berichte, die ein roter Lauf geschrieben hatte, blieben auf der Festplatte, wo der Watcher sie einen Moment später lud. Sie werden jetzt entfernt.
• Die Kopie, die ein TRX-Logger von einem Coverage-Bericht anlegt, wird nie für ein Tracefile gehalten.

Hinzugefügt

• Run Tests Affected by My Changes… listet die Tests auf, die eine Zeile ausgeführt haben, die der Arbeitsbaum gegenüber fuciniCoverage.testImpact.baseRef (standardmäßig HEAD) ändert, zuerst den, 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.

Behoben

• testRun.skipWhenTestsFail gilt über den Lauf hinaus. Die Berichte, die ein roter Lauf geschrieben hatte, blieben auf der Festplatte, wo der Watcher sie einen Moment später lud. Sie werden jetzt entfernt.
• Die Kopie, die ein TRX-Logger von einem Coverage-Bericht anlegt, wird nie für ein Tracefile gehalten.

Hinzugefügt

• Bestanden oder fehlgeschlagen an den Markierungen. Eine Zeile, die ein fehlschlagender Test ausgeführt hat, bekommt einen roten Balken an ihrem Anfang, und ihr Hover nennt die fehlgeschlagenen Tests; Show Tests That Ran This Line sagt, welche der Tests fehlgeschlagen sind. Dazu braucht es einen Bericht, der sagt, welche Tests eine Zeile ausgeführt haben, und die Ergebnisdatei des Runners — TRX oder JUnit XML — im Ordner des Berichts oder in fuciniCoverage.testResults.paths genannt. Run Tests with Coverage fordert jetzt eine von dotnet test an.
• Die eigene Code Coverage von Visual Studio, geladen. Die .coverage-Datei, die Analyze Code Coverage von Visual Studio schreibt, wird mit dotnet-coverage konvertiert und von selbst geladen: Coverage Studio baut auf dem eingebauten Collector auf, statt mit ihm zu konkurrieren.

Hinzugefügt

• Bestanden oder fehlgeschlagen an den Markierungen. Eine Zeile, die ein fehlschlagender Test ausgeführt hat, bekommt einen roten Balken an ihrem Anfang, und ihr Hover nennt die fehlgeschlagenen Tests; Show Tests That Ran This Line sagt, welche der Tests fehlgeschlagen sind. Dazu braucht es einen Bericht, der sagt, welche Tests eine Zeile ausgeführt haben, und die Ergebnisdatei des Runners — TRX oder JUnit XML — im Ordner des Berichts oder in fuciniCoverage.testResults.paths genannt. Run Tests with Coverage fordert jetzt eine von dotnet test an.

Behoben

• Das Suchfeld behält seine Abfrage und seinen Fokus, wenn die Coverage neu geladen wird. Jedes Neuladen leerte es, oft noch während die Abfrage getippt wurde. Eine Abfrage wie < 80% behält außerdem die Risiko-Hotspots, auf die sie passt.
• Eine Coverage-Sitzung zählt denselben Lauf nicht mehr doppelt. Jedes Neuladen unveränderter Berichte addierte sie erneut, und jede Trefferzahl verdoppelte sich. Eine Sitzung behält jetzt jeden Satz von Berichten einmal.
• Die CI-Baseline hält ein Laden nicht mehr auf. Zuerst wird das Geladene gezeichnet, der Vergleich folgt. Die Baseline wird einmal aufbereitet und behalten, solange ihr Bericht und die Einstellungen gleich bleiben, und wenn die URL nicht erreichbar ist, wird die zuvor abgerufene Kopie verwendet.
• „Seit dem letzten Lauf“ übersteht ein Neuladen unveränderter Berichte. Eine Änderung der Einstellungen oder ein Aktualisieren machte den Lauf auf dem Bildschirm zu seinem eigenen letzten Lauf, und jede Änderung seit dem Lauf davor verschwand. Ein solches erneutes Einlesen wird auch nicht mehr in der Historie aufbewahrt.
• Ein Laden nach dem anderen. Zwei zusammen angeforderte Neuladevorgänge liefen nebeneinander, und der langsamere gewann. Was während eines Ladens an Neuladen angefordert wird, wird jetzt zu einem einzigen Laden danach.
• Eine CI-Baseline über HTTP wird abgerufen wie in VS Code. Ein Client, die letzte Kopie aufbewahrt für den Fall, dass der Server nicht erreichbar ist, und remote.headers nur an die Adresse gesendet, für die sie geschrieben wurden — nie über unverschlüsseltes HTTP.
• Ein Befehl, dessen Arbeit fehlschlägt, sagt es. Ein Fehler in einem Befehl oder einem Timer wurde verschluckt; er ist jetzt eine Zeile im Ausgabefenster.
• Weniger Arbeit auf dem UI-Thread. Die Datei-Watcher werden im Hintergrund angelegt, die Einträge der Fehlerliste werden einmal je Laden ermittelt, und das Log wird in Schüben statt Zeile für Zeile geschrieben.
• Zwei Visual-Studio-Fenster beschädigen die Historie der Läufe nicht mehr. Ihr Index wird in einem Schritt unter einer Sperre ersetzt, die beide teilen, und aus den Läufen neu erstellt, wenn er verloren geht.
• Run Native Project with Coverage baut die eigene Plattform des Projekts und nimmt llvm-cov und llvm-profdata als Paar aus dem LLVM des Compilers.
• Die Farben für Warnung, Fehler und Bestanden im Coverage-Fenster folgen einem hellen Design ebenso wie einem dunklen.
• Eine Einstellungsdatei, die mit ungespeicherten Änderungen geöffnet ist, wird nicht überschrieben. Die Einstellungsseite sagt, dass sie zuerst zu speichern ist.

Geändert

• Eine Coverage-Datei, die Sie auswählen, und der Bericht, den ein Testlauf schreibt, werden für Sie gemerkt, statt in .vscode/settings.json geschrieben zu werden. Diese Datei wird oft committet, sodass ein Testlauf eine Änderung im Repository hinterließ, um die niemand gebeten hatte. Pfade, die schon in coverageFile.paths stehen, funktionieren weiter.

Behoben

• Das Suchfeld behält seine Abfrage und seinen Fokus, wenn die Coverage neu geladen wird. Jedes Neuladen leerte es, oft noch während die Abfrage getippt wurde. Eine Abfrage wie < 80% behält außerdem die Risiko-Hotspots, auf die sie passt.
• Eine Coverage-Sitzung zählt denselben Lauf nicht mehr doppelt. Jedes Neuladen unveränderter Berichte addierte sie erneut, und jede Trefferzahl verdoppelte sich. Eine Sitzung behält jetzt jeden Satz von Berichten einmal.
• Die CI-Baseline hält ein Laden nicht mehr auf. Zuerst wird das Geladene gezeichnet, der Vergleich folgt. Die Baseline wird einmal aufbereitet und behalten, solange ihr Bericht und die Einstellungen gleich bleiben, und wenn die URL nicht erreichbar ist, wird die zuvor abgerufene Kopie verwendet.
• Die Prüfung auf geänderte Berichtsdateien läuft einen Durchgang nach dem anderen. Auf einem langsamen Netzlaufwerk sahen zwei Durchgänge dieselbe Änderung, und die Coverage wurde zweimal geladen.
• „Seit dem letzten Lauf“ übersteht ein Neuladen unveränderter Berichte. Eine Änderung der Einstellungen oder ein Aktualisieren machte den Lauf auf dem Bildschirm zu seinem eigenen letzten Lauf, und jede Änderung seit dem Lauf davor verschwand. Ein solches erneutes Einlesen wird auch nicht mehr in der Historie aufbewahrt.

Geändert

• Eine Coverage-Datei, die Sie auswählen, und der Bericht, den ein Testlauf schreibt, werden für Sie gemerkt, statt in .vscode/settings.json geschrieben zu werden. Diese Datei wird oft committet, sodass ein Testlauf eine Änderung im Repository hinterließ, um die niemand gebeten hatte. Pfade, die schon in coverageFile.paths stehen, funktionieren weiter.

Behoben

• Eine .NET-Solution mit zwei oder mehr Testprojekten verliert nicht mehr die Coverage aller Projekte bis auf eines. dotnet test schrieb einen Bericht je Projekt, und alle wurden auf dasselbe coverage/coverage.cobertura.xml verschoben, sodass nur der letzte geladen wurde. Ein solcher Ordner führt dotnet test jetzt einmal je Testprojekt aus, jeder Bericht kommt nach coverage/<Project>/, und der Lauf eines Projekts ersetzt nur den Bericht dieses Projekts.
• Mehrere Dateien auf einmal zu speichern führt die Tests jeder gespeicherten Datei aus. Mit testRun.onSave liefen nur die Tests der letzten Datei; Speichervorgänge, die während eines Laufs eintreffen, werden aufbewahrt und danach zusammen ausgeführt.
• Run This Test with Coverage und die Läufe je Test führen genau das aus, was sie nennen. Der .NET-Filter verglich nach Teilzeichenfolge: Total führte auch TotalTax aus. Ein Test läuft jetzt über seinen genauen Namen, eine Klasse über ihren Namen gefolgt von einem Punkt, und ein Test in einer verschachtelten Klasse wird gefunden (Outer+Inner).
• Ein jest- oder vitest-Test, dessen Titel (, + oder $ enthält, läuft. Der Titel ging an -t, das einen regulären Ausdruck liest, sodass ein solcher Test auf nichts passte und nichts lief.
• Run This Test with Coverage liest VB- und F#-Testdateien. <Fact> über Public Sub und [<Fact>] über let oder member wurden nie erkannt.
• Das Abbrechen eines Testlaufs beendet jeden Prozess, den er gestartet hat. Nur die Shell wurde beendet, und dotnet test lief dahinter weiter. Das Schließen von Visual Studio bricht den Lauf ebenfalls ab.
• Tippen während eines Laufs nach dem Speichern verschiebt die Markierungen nicht mehr. Sie sind an den Text geheftet, den der Lauf gemessen hat.
• Eine Solution auf einer Netzwerkfreigabe führt ihre Tests dort aus. Der Lauf startete in C:\Windows, weil die Befehlsshell einen Pfad wie \\server\share nicht als ihren Ordner annimmt.

Behoben

• Eine .NET-Solution mit zwei oder mehr Testprojekten verliert nicht mehr die Coverage aller Projekte bis auf eines. dotnet test schrieb einen Bericht je Projekt, und alle wurden auf dasselbe coverage/coverage.cobertura.xml verschoben, sodass nur der letzte geladen wurde. Ein solcher Ordner führt dotnet test jetzt einmal je Testprojekt aus, jeder Bericht kommt nach coverage/<Project>/, und der Lauf eines Projekts ersetzt nur den Bericht dieses Projekts.
• Mehrere Dateien auf einmal zu speichern führt die Tests jeder gespeicherten Datei aus. Mit testRun.onSave liefen nur die Tests der letzten Datei; Speichervorgänge, die während eines Laufs eintreffen, werden aufbewahrt und danach zusammen ausgeführt.
• Run This Test with Coverage und die Läufe je Test führen genau das aus, was sie nennen. Der .NET-Filter verglich nach Teilzeichenfolge: Total führte auch TotalTax aus. Ein Test läuft jetzt über seinen genauen Namen, eine Klasse über ihren Namen gefolgt von einem Punkt, und ein Test in einer verschachtelten Klasse wird gefunden (Outer+Inner).
• Ein jest- oder vitest-Test, dessen Titel (, + oder $ enthält, läuft. Der Titel ging an -t, das einen regulären Ausdruck liest, sodass ein solcher Test auf nichts passte und nichts lief.
• Ein Testtitel mit Anführungszeichen kommt ganz im Terminal an. Ein Befehl mit \" innerhalb von Anführungszeichen zerfiel am ersten davon.
• Run This Test with Coverage liest VB- und F#-Testdateien. <Fact> über Public Sub und [<Fact>] über let oder member wurden nie erkannt.
• Ein Test-Task, der endet, ohne einen Prozess zu starten, lässt Run Tests with Coverage nicht mehr ewig warten. Der Befehl endet und sagt, dass der Lauf nichts geschrieben hat.

Hinzugefügt

• Welche Tests diese Zeile ausgeführt haben. Wo der Bericht es festhält — coverage.py mit --show-contexts, die Tracked Methods von OpenCover, ein je Test geschriebenes lcov-Tracefile — sagt die CodeLens einer Funktion, wie viele Tests sie ausgeführt haben, und Show Tests That Ran This Line listet sie auf, die fleißigsten zuerst, und öffnet den gewählten. Für einen dotnet test-Lauf führt testRun.perTest die Tests Klasse für Klasse aus, sodass jeder Bericht sagt, welche Klasse ihn geschrieben hat.
• Coverage nach jedem Speichern. Mit testRun.onSave führt das Speichern einer Quelldatei die Tests aus, die sie abdecken, mit Coverage, und der Randstreifen folgt. In einer .NET-Solution laufen nur die Testprojekte, die auf das Projekt der gespeicherten Datei verweisen; mehrmaliges Speichern hintereinander ist ein Lauf.
• Run This Test with Coverage. Mit dem Cursor in einer Testmethode, einer Testklasse oder einem describe oder in einer Testdatei führt ein Befehl genau das mit Coverage aus — dotnet test --filter, jest/vitest -t oder eine pytest-Node-ID — und lädt, was dabei geschrieben wurde. Der Test wird aus dem Text gelesen, deshalb funktioniert es für C#, VB, F#, JavaScript, TypeScript und Python ohne Sprachdienst.
• Exclude from Coverage und zwei .NET-Filter. Ein Rechtsklick auf eine Zeile des Coverage-Baums oder Exclude This File from Coverage für die geöffnete Datei trägt die Datei oder den Ordner in fuciniCoverage.ignore ein, und sie verlässt jede Summe. ignore.namespaces lässt die Dateien eines Namespace weg (*.Migrations), ignore.attributes die Klasse, Methode oder Property unter einem Attribut — standardmäßig ExcludeFromCodeCoverage, das OpenCover, dotCover und ein konvertiertes lcov nicht beachten.
• Exclude Selection from Coverage. Zeilen markieren und die Aktion aus der Glühbirne oder dem Kontextmenü des Editors wählen: Über einer .NET-Klasse, -Methode oder -Property schreibt sie [ExcludeFromCodeCoverage] — in der Kurzform, wenn die Datei System.Diagnostics.CodeAnalysis schon importiert —, sonst LCOV_EXCL_LINE oder ein Paar LCOV_EXCL_START/STOP im Kommentar der jeweiligen Sprache. Eine vorhandene Markierung wird nicht verdoppelt.
• Namespaces, Klassen und Methoden. Für einen .NET-Bericht, der seine Klassen nennt — Cobertura, Coverlet, OpenCover —, zeigt eine Auswahl Folders / Namespaces denselben Lauf nach Namespace, Klasse und Methode, mit derselben Sortierung und demselben Filter; eine Methodenzeile öffnet die Datei an der Methode. Vom Compiler erzeugte Typen wie <>c und async-Zustandsautomaten werden in die Klasse eingefaltet, für die sie erzeugt wurden.
• Ein Suchfeld über dem Coverage-Baum. Wörter eingeben, um die Zeilen zu behalten, deren Name oder Pfad sie alle enthält, oder einen Vergleich — < 80%, lines >= 90, branches = 0 —, um die Zeilen zu behalten, deren Wert ihn erfüllt; beides zusammen verlangt beides. Methodenzeilen und Risiko-Hotspots werden mit durchsucht; Escape leert das Feld.
• Run Native Project with Coverage. Das C++-Startprojekt, aus dem Menü Tools: Ein ClangCL-Projekt wird mit der Coverage-Instrumentierung von clang nach coverage/native/ neu gebaut, ausgeführt und sein Bericht geladen; jedes andere Toolset läuft unter OpenCppCoverage, wo es installiert ist, und wo beides nicht geht, sagt ein Satz, was zu installieren ist.
• Coverage-Sitzungen und ein Trend. Start Coverage Session, und jeder danach geladene Lauf wird zu den vorigen addiert — Zeilen, Branches und Funktionen gleichermaßen: Was irgendeiner von ihnen ausgeführt hat, ist abgedeckt —, sodass Unit-Tests, Integrationstests und ein Durchgang durch die Anwendung zeigen, was sie zusammen erreicht haben. Unter der Symbolleiste wird die Zeilenabdeckung der gespeicherten Historie als Trend gezeichnet, ein Punkt je Lauf.
• Compare Two History Runs, wie in VS Code: zwei aufbewahrte Läufe wählen, und die Dateien, die sich zwischen ihnen bewegt haben, werden vom älteren zum neueren aufgelistet, egal welcher zuerst gewählt wurde.
• Compare with CI Baseline. baseline.report nennt den Bericht, den der Build Ihres Hauptbranchs veröffentlicht — eine URL, abgerufen mit remote.headers, oder eine heruntergeladene Datei —, und jedes Laden wird daran gemessen: Die Karte der Statusleiste sagt, wo dieser Lauf steht, und Compare with CI Baseline listet die Dateien, die sich bewegt haben. Die Baseline durchläuft dieselbe Ausschlussliste wie der Lauf, damit die Summen Gleiches mit Gleichem vergleichen.
• Wo sie zu finden sind. Die neuen Befehle stehen unter Tools > Coverage Studio und im Kontextmenü des Editors; Show Tests That Ran This Line ist auch Ctrl+Shift+U, T, und Exclude Selection from Coverage ist eine Glühbirnen-Aktion.

Behoben

• Der Bericht eines Testlaufs trägt nicht mehr Ihren Benutzer- und Rechnernamen. Der Code-Coverage-Collector von Microsoft nennt seinen Bericht <user>_<machine>_<stamp>.cobertura.xml, und dieser Name stand im Baum und auf jedem Screenshot davon; der Bericht wird nun vor dem Laden in coverage.cobertura.xml umbenannt.
• Von einer generierten Datei hieß es, fuciniCoverage.ignore lasse sie weg. Jede weggelassene Datei wird nun unter der Einstellung gezählt, die sie weggelassen hat — ignore, ignore.generated oder ignore.namespaces —, sodass der angezeigte Name der ist, den man ändern muss.
• Ein je Test geschriebenes lcov-Tracefile wird als ein Datensatz je Datei gelesen, die Testabschnitte addiert, wie VS Code es liest; bisher war der Datensatz jedes Tests eine eigene Datei.
• Das Log sagt, was ein Parser weggelassen hat. Die Dateien, in denen ein Parser nichts zu instrumentieren fand (FUCINI_PARSE_030), und die eigene Auskunft eines Berichts über seine Lücken (FUCINI_PARSE_031, OpenCovers MissingPdb) werden ins Log geschrieben, wie VS Code sie schreibt.
• Ein Header voller Makros steht nicht mehr mit 100% im Baum. llvm-cov und gcov rechnen die Verwendungen eines Makros den Zeilen zu, die es definieren; die Branches und Funktionen auf ausgeschlossenen Zeilen gehen jetzt mit den Zeilen, und eine Datei ohne Messbares wird aus dem Lauf genommen und in der Ausgabe genannt (FUCINI_EXCLUDE_001).
• Fünf Berichte, die als nicht unterstütztes Format abgelehnt wurden, werden erkannt. Das JaCoCo-XML von Kover, ein Stryker.NET-Bericht, ein NCover-Bericht, ein altes SimpleCov-Resultset und ein SonarQube-Bericht mit vielen leeren Dateien werden jetzt an dem erkannt, was sie am Anfang tragen. Ein Clover- oder SonarQube-Bericht, dessen Pfade das Wort cobertura enthalten, wird nicht mehr als Cobertura gelesen.
• Zahlen, die mit den Werkzeugen übereinstimmen, die sie geschrieben haben. Der Branch-Wert eines MC/DC-Builds stimmt mit llvm-cov report überein; Exception-Branches von LCOV 2 (BRDA:12,e0,1,3) zählen; eine llvm-cov-Funktion wird nur in der Datei deklariert, die sie definiert; ein Go-Block, den zwei Test-Binaries aufführen, addiert seine Zählungen; eine Cobertura-Entscheidung, die zwei Klassen melden, und eine doppelt aufgeführte JaCoCo-Zeile behalten alle ihre Zweige, einmal.
• Kleinere. Ein mitten im Schreiben abgebrochenes Tracefile verliert keine Datei mehr; gcov -t über mehrere .gcda-Dateien ergibt je eine Datei, Template-Instanziierungen werden einmal gelesen und Zählungen wie 1.20k aus gcov -H bleiben erhalten; GNATcoverage-Dateien werden nicht mehr alle als seit ihrer Coverage geändert gemeldet; ein wartender Stryker-Mutant oder ein abgebrochener PIT-Lauf zählt nicht mehr gegen den Score.
• Eine Änderung der Einstellungsdatei von Hand wird beim Speichern angewendet, wie VS Code eine geänderte Einstellung anwendet.

Hinzugefügt

• Welche Tests diese Zeile ausgeführt haben. Wo der Bericht es festhält — coverage.py mit --show-contexts, die Tracked Methods von OpenCover, ein je Test geschriebenes lcov-Tracefile — sagt die CodeLens einer Funktion, wie viele Tests sie ausgeführt haben, und Show Tests That Ran This Line listet sie auf, die fleißigsten zuerst, und öffnet den gewählten. Für einen dotnet test-Lauf führt testRun.perTest die Tests Klasse für Klasse aus, sodass jeder Bericht sagt, welche Klasse ihn geschrieben hat.
• Coverage nach jedem Speichern. Mit testRun.onSave führt das Speichern einer Quelldatei die Tests aus, die sie abdecken, mit Coverage, und der Randstreifen folgt. In einer .NET-Solution laufen nur die Testprojekte, die auf das Projekt der gespeicherten Datei verweisen; mehrmaliges Speichern hintereinander ist ein Lauf.
• Run This Test with Coverage. Mit dem Cursor in einer Testmethode, einer Testklasse oder einem describe oder in einer Testdatei führt ein Befehl genau das mit Coverage aus — dotnet test --filter, jest/vitest -t oder eine pytest-Node-ID — und lädt, was dabei geschrieben wurde. Der Test wird aus dem Text gelesen, deshalb funktioniert es für C#, VB, F#, JavaScript, TypeScript und Python ohne Sprachdienst.
• Exclude from Coverage und zwei .NET-Filter. Ein Rechtsklick auf eine Zeile des Coverage-Baums oder Exclude This File from Coverage für die geöffnete Datei trägt die Datei oder den Ordner in fuciniCoverage.ignore ein, und sie verlässt jede Summe. ignore.namespaces lässt die Dateien eines Namespace weg (*.Migrations), ignore.attributes die Klasse, Methode oder Property unter einem Attribut — standardmäßig ExcludeFromCodeCoverage, das OpenCover, dotCover und ein konvertiertes lcov nicht beachten.
• Exclude Selection from Coverage. Zeilen markieren und die Aktion aus der Glühbirne oder dem Kontextmenü des Editors wählen: Über einer .NET-Klasse, -Methode oder -Property schreibt sie [ExcludeFromCodeCoverage] — in der Kurzform, wenn die Datei System.Diagnostics.CodeAnalysis schon importiert —, sonst LCOV_EXCL_LINE oder ein Paar LCOV_EXCL_START/STOP im Kommentar der jeweiligen Sprache. Eine vorhandene Markierung wird nicht verdoppelt.
• Namespaces, Klassen und Methoden. Für einen .NET-Bericht, der seine Klassen nennt — Cobertura, Coverlet, OpenCover —, zeigt eine Auswahl Folders / Namespaces denselben Lauf nach Namespace, Klasse und Methode, mit derselben Sortierung und demselben Filter; eine Methodenzeile öffnet die Datei an der Methode. Vom Compiler erzeugte Typen wie <>c und async-Zustandsautomaten werden in die Klasse eingefaltet, für die sie erzeugt wurden.
• Ein Suchfeld über dem Coverage-Baum. Wörter eingeben, um die Zeilen zu behalten, deren Name oder Pfad sie alle enthält, oder einen Vergleich — < 80%, lines >= 90, branches = 0 —, um die Zeilen zu behalten, deren Wert ihn erfüllt; beides zusammen verlangt beides. Methodenzeilen und Risiko-Hotspots werden mit durchsucht; Escape leert das Feld.
• Coverage-Sitzungen und ein Trend. Start Coverage Session, und jeder danach geladene Lauf wird zu den vorigen addiert — Zeilen, Branches und Funktionen gleichermaßen: Was irgendeiner von ihnen ausgeführt hat, ist abgedeckt —, sodass Unit-Tests, Integrationstests und ein Durchgang durch die Anwendung zeigen, was sie zusammen erreicht haben. Unter der Symbolleiste wird die Zeilenabdeckung der gespeicherten Historie als Trend gezeichnet, ein Punkt je Lauf.
• Compare with CI Baseline. baseline.report nennt den Bericht, den der Build Ihres Hauptbranchs veröffentlicht — eine URL, abgerufen mit remote.headers, oder eine heruntergeladene Datei —, und jedes Laden wird daran gemessen: Die Karte der Statusleiste sagt, wo dieser Lauf steht, und Compare with CI Baseline listet die Dateien, die sich bewegt haben. Die Baseline durchläuft dieselbe Ausschlussliste wie der Lauf, damit die Summen Gleiches mit Gleichem vergleichen.

Behoben

• Der Bericht eines Testlaufs trägt nicht mehr Ihren Benutzer- und Rechnernamen. Der Code-Coverage-Collector von Microsoft nennt seinen Bericht <user>_<machine>_<stamp>.cobertura.xml, und dieser Name stand im Baum und auf jedem Screenshot davon; der Bericht wird nun vor dem Laden in coverage.cobertura.xml umbenannt.
• Ein Testlauf schlug unter Windows fehl, wenn das Terminal PowerShell ist. Die Anführungszeichen um Code Coverage;Format=cobertura gingen auf dem Weg zu pwsh verloren, das das ; als Ende des Befehls las; das Rezept wird dem Terminal nun Wort für Wort übergeben und für die Shell gequotet, die es startet.
• Von einer generierten Datei hieß es, fuciniCoverage.ignore lasse sie weg. Jede weggelassene Datei wird nun unter der Einstellung gezählt, die sie weggelassen hat — ignore, ignore.generated oder ignore.namespaces —, sodass der angezeigte Name der ist, den man ändern muss.
• Ein Header voller Makros steht nicht mehr mit 100% im Baum. llvm-cov und gcov rechnen die Verwendungen eines Makros den Zeilen zu, die es definieren; die Branches und Funktionen auf ausgeschlossenen Zeilen gehen jetzt mit den Zeilen, und eine Datei ohne Messbares wird aus dem Lauf genommen und in der Ausgabe genannt (FUCINI_EXCLUDE_001).
• Fünf Berichte, die als nicht unterstütztes Format abgelehnt wurden, werden erkannt. Das JaCoCo-XML von Kover, ein Stryker.NET-Bericht, ein NCover-Bericht, ein altes SimpleCov-Resultset und ein SonarQube-Bericht mit vielen leeren Dateien werden jetzt an dem erkannt, was sie am Anfang tragen. Ein Clover- oder SonarQube-Bericht, dessen Pfade das Wort cobertura enthalten, wird nicht mehr als Cobertura gelesen.
• Zahlen, die mit den Werkzeugen übereinstimmen, die sie geschrieben haben. Der Branch-Wert eines MC/DC-Builds stimmt mit llvm-cov report überein; Exception-Branches von LCOV 2 (BRDA:12,e0,1,3) zählen; eine llvm-cov-Funktion wird nur in der Datei deklariert, die sie definiert; ein Go-Block, den zwei Test-Binaries aufführen, addiert seine Zählungen; eine Cobertura-Entscheidung, die zwei Klassen melden, und eine doppelt aufgeführte JaCoCo-Zeile behalten alle ihre Zweige, einmal.
• Kleinere. Ein mitten im Schreiben abgebrochenes Tracefile verliert keine Datei mehr; gcov -t über mehrere .gcda-Dateien ergibt je eine Datei, Template-Instanziierungen werden einmal gelesen und Zählungen wie 1.20k aus gcov -H bleiben erhalten; GNATcoverage-Dateien werden nicht mehr alle als seit ihrer Coverage geändert gemeldet; ein wartender Stryker-Mutant oder ein abgebrochener PIT-Lauf zählt nicht mehr gegen den Score.

Geändert

• Kein FUCINI_ENCODING_001 mehr bei jedem Laden. Ein Bericht ohne Byte-Order-Mark wird als UTF-8 gelesen, wie jedes Werkzeug ihn schreibt, ohne einen Hinweis darauf.

Hinzugefügt

• Ein relativer Eintrag mit Platzhalter wird in beliebiger Tiefe gesucht. *.lcov.info in coverageFile.paths findet die Datei, wo immer sie unterhalb des Basisordners liegt, so wie VS Code ihn schon immer gelesen hat; ein absoluter Eintrag — ${workspaceFolder}/build/coverage-merged/*.lcov.info, ** für beliebige Tiefe — sucht genau dort, wo er es sagt, wie bisher.
• Beobachtet, wo der Bericht erscheinen wird. Die Beobachtung umfasst die Ordner, die die Einstellungen nennen, ob dort schon ein Bericht liegt oder nicht: den Ordner einer absolut angegebenen Datei, die Ordner vor einem Platzhalter — mit allem darunter, wenn das Muster in Unterordner reicht — und den Basisordner für einen relativen Platzhalter. Ein Bericht, den ein Build dort schreibt, lädt von selbst; ein Schreibzugriff auf eine andere Datei in diesen Ordnern wird ignoriert.

Behoben

• Ein llvm-cov-JSON-Bericht wurde als nicht unterstütztes Format abgewiesen. Das Format wird an den ersten 4096 Zeichen erkannt, und llvm-cov schreibt seine Markierung "type": "llvm.coverage.json.export" ganz ans Ende; ein Export, dessen erster Dateieintrag viele Branches und verschachtelte Makro-Expansionen trägt, hatte in diesem Kopf sonst nichts Erkennbares. Ein solcher Bericht wird jetzt an seinem Anfang erkannt, {"data":[{"files":[, den kein anderes Format hat.
• Dasselbe für gcov --json-format. gcov schreibt die Funktionen einer Datei vor ihren Zeilen, und eine Datei mit einem Dutzend Funktionen hat im untersuchten Kopf ebenfalls keinen Zeileneintrag; der eigene Schlüssel gcc_version des Dokuments identifiziert es jetzt.

Hinzugefügt

• Ein Platzhalter in einem absoluten coverageFile.paths-Eintrag. ${workspaceFolder}/build/coverage-merged/*.lcov.info lädt jede solche Datei in diesem Ordner, und ** steht für beliebige Tiefe: Die Ordner vor dem ersten Platzhalter werden durchsucht, der Rest ist das Muster darunter, so wie die Visual-Studio-Edition einen solchen Eintrag schon immer gelesen hat. Zuvor wurde ein absoluter Eintrag so gesucht, wie er geschrieben war, sodass einer mit Stern auf nichts passte — und, als Platzhalter, auch nie als nicht passend gemeldet wurde. Ein Bericht, der dort später erscheint, wird vom Watcher oder von der Abfrage wie ein wörtlicher Eintrag geladen; ein Platzhalter, der auf nichts passt, wird nicht gemeldet, da er auf einen Build warten kann.

Behoben

• Ein llvm-cov-JSON-Bericht wurde als nicht unterstütztes Format abgewiesen. Das Format wird an den ersten 4096 Zeichen erkannt, und llvm-cov schreibt seine Markierung "type": "llvm.coverage.json.export" ganz ans Ende; ein Export, dessen erster Dateieintrag viele Branches und verschachtelte Makro-Expansionen trägt, hatte in diesem Kopf sonst nichts Erkennbares. Ein solcher Bericht wird jetzt an seinem Anfang erkannt, {"data":[{"files":[, den kein anderes Format hat.
• Dasselbe für gcov --json-format. gcov schreibt die Funktionen einer Datei vor ihren Zeilen, und eine Datei mit einem Dutzend Funktionen hat im untersuchten Kopf ebenfalls keinen Zeileneintrag; der eigene Schlüssel gcc_version des Dokuments identifiziert es jetzt.

Hinzugefügt

• Die Berichte einer Datei wählen oder kombinieren. Klicken Sie im Coverage-Fenster mit der rechten Maustaste auf eine Datei und wählen Sie Choose Coverage Source... — angeboten, wo mehr als ein geladener Bericht sie misst — oder verwenden Sie Tools > Coverage Studio > Choose Coverage Source for This File...: jeder Bericht mit seinen eigenen Zahlen, dann Combine them — agree (abgedeckt nur, wo jeder Bericht eine Zeile ausgeführt hat: eine Codebasis, zwei Compiler) und — union (abgedeckt, wo irgendeiner es tat: mehrere Testsuiten eines Builds), für die Datei, ihren Ordner oder ein Muster. Die Zeilen, in denen die Berichte voneinander abweichen, sind im Rand und in der Annotated Source türkis, mit dem, was jeder Bericht gesagt hat; die Zeile nennt die Berichte und die Zahl der strittigen Zeilen, und die Statusleiste und beide Karten sagen, woher die Zahlen stammen.
• Rot, Bernstein und Grün. Gutter: Coverage färbt jede abgedeckte Zeile grün, neben Rot und Bernstein — der Modus für alle, die erwartet haben, dass eine Datei mit 100 % grün ist. Die fünf Farbtöne der Heatmap sind Einstellungen (heatmap.colors, heatmap.colorsDark), und das Einstellungsfenster zeigt jede Farbe als Vorschau, während sie gewählt wird.

Behoben

• Die Zahl der Datei in der Statusleiste ist die ihrer Karte. Eine Metrik ohne Inhalt — MC/DC in einer Datei ohne Entscheidungen — zählte im Element als 100 % und auf der Karte, die es öffnet, gar nicht.
• Ein Header aus Konstanten zeigt nicht mehr 0 % oder 100 %. Präprozessor-Direktiven zählen wie Kommentare als kein Code, wenn excludeComments eingeschaltet ist.

Hinzugefügt

• Die Berichte einer Datei wählen oder kombinieren. coverageFile.sources entscheidet je Datei, welcher von mehreren geladenen Berichten für sie spricht — oder kombiniert sie: agree zählt eine Zeile nur dort als abgedeckt, wo jeder Bericht sie ausgeführt hat, und markiert die Zeilen, in denen sie voneinander abweichen, türkis; union dort, wo irgendeiner es tat. Choose Coverage Source... auf einer Zeile der Coverage-Ansicht oder für die offene Datei schreibt die Regel für Sie. Teil der kostenpflichtigen Pläne; in Community entscheidet der neueste Bericht.
• Rot, Bernstein und Grün, und ein Gutter-Modus mit einem Klick. Der Modus coverage färbt abgedeckte Zeilen grün; die Farbtöne der Heatmap sind Einstellungen mit Live-Vorschau im Einstellungsbereich; eine Schaltfläche in der Statusleiste und Alt+G schalten den Gutter reihum durch aus, nicht abgedeckt, Coverage und Heatmap.

Behoben

• Die Zahl der Datei in der Statusleiste ist die ihrer Karte. Eine Metrik ohne Inhalt — MC/DC in einer Datei ohne Entscheidungen — zählte im Element als 100 % und auf der Karte, die es öffnet, gar nicht.
• Ein Header aus Konstanten zeigt nicht mehr 0 % oder 100 %. Präprozessor-Direktiven zählen wie Kommentare als kein Code, wenn excludeComments eingeschaltet ist.

Geändert

• Der Lizenzdialog fragt nur noch nach dem Code. Die vier Plan-Schaltflächen sind weg: Ein Abonnement- oder Einladungscode benennt einen Pool, und der Pool kennt seinen Plan, also gab es nichts, was eine Person besser hätte beantworten können als der Code selbst — und eine Business-Einladung, eingefügt, während noch Pro ausgewählt war, wurde wegen des falschen Plans abgelehnt. Fügen Sie den Code ein und drücken Sie Activate.

Geändert

• Enter Subscription Code fragt nur noch nach dem Code. Die Frage nach dem Plan ist weg: Der Code benennt einen Pool, und der Pool kennt seinen Plan, also übernimmt der Server von dort und lehnt einen Code nicht mehr als zum falschen Plan gehörig ab. Die Ein-Klick-Links in den E-Mails sind unverändert; die Aktivierungs-E-Mails haben keinen Schritt „Plan wählen“ mehr, und derselbe Code aktiviert Coverage Studio für Visual Studio ganz ohne VS Code.

Hinzugefügt

• Coverage nach jedem Testlauf. Collect Coverage in Test Explorer… legt eine .runsettings mit Microsofts Cobertura-Collector neben die Projektmappe — von selbst aufgenommen, wenn Tools → Options → Test → Auto detect runsettings files eingeschaltet ist, oder einmal unter Test → Configure Run Settings ausgewählt; von da an schreibt jeder Test-Explorer-Lauf einen Bericht unter das Testprojekt, und er wird in dem Moment geladen, in dem er erscheint, zusammengeführt mit allem, was die Einstellungen benennen. Nichts hängt sich in den Test Explorer ein, sodass Visual Studio 2026 und Microsoft.Testing.Platform funktionieren, wie sie sind. Run Tests with Coverage erkennt dotnet test, vitest, jest, pytest, go, cargo, maven, gradle, phpunit und ctest, führt sie mit eingeschalteter Coverage im Output-Fenster aus und lädt, was sie geschrieben haben; ein Testprojekt ohne coverlet.collector wird mit dem Collector ausgeführt, den das Test-SDK mitbringt.
• Seit dem letzten Lauf. Jedes Laden wird mit dem davor verglichen: ein Dreieck in der Randleiste an jeder Zeile, die zu laufen begonnen oder aufgehört hat, der Trend neben dem Wert und Compare with Last Run für die Dateien, deren Zahlen sich bewegt haben. history.enabled behält die Läufe über Neustarts hinweg; gitDiff.enabled schneidet den Lauf auf die Zeilen zu, die Ihr Branch geändert hat.
• Die Gates und die Error List. Check Coverage Thresholds beurteilt den Lauf anhand von threshold.*; mit compliance.diagnostics, problems.enabled, problems.perLine oder deadCode.enabled stehen die Befunde in der Error List neben denen des Compilers, und jeder öffnet seine Datei.
• Berichte, Exporte und ein Badge. Show Annotated Source öffnet die aktive Datei als Seite im Dokumentbereich — jede Zeile in ihrer Farbe, die Befunde daneben — und scrollt in beiden Richtungen mit dem Editor. Open HTML Report und Generate Full HTML Report schreiben den Lauf nach htmlReport.outputDir und öffnen den Browser. Export Coverage Report… schreibt CSV je Datei oder je Funktion, Markdown, LCOV, Cobertura, SARIF, ein SVG-Badge oder Fucini JSON. Generate Coverage Badge hält das Badge im Repository, mit badge.autoUpdate nach jedem Laden.
• Risk hotspots und Zeilenfilter im Coverage-Fenster, wie in VS Code: die Funktionen, in denen komplexer Code auf wenig Coverage trifft, die schlimmste zuerst; und ein Dropdown neben der Sortierung für alle Dateien, Dateien mit Lücken, ungetestete Dateien oder die seit dem letzten Lauf geänderten Dateien.
• Eine Einstellungsdatei im Stammordner der Projektmappe. fucini-coverage.json neben der Projektmappe wird nach .vscode/settings.json gelesen und vom Einstellungsfenster geschrieben, wenn sie die Datei ist, die vorhanden ist — für ein Team, das lieber keinen .vscode-Ordner hält. Beide Editionen lesen sie.
• .NET ohne Umstände. ignore.generated lässt Designer-, generierte, obj\- und Migrationsdateien aus jeder Summe heraus; testRun.skipWhenTestsFail behält die letzte gute Coverage auf dem Bildschirm, wenn ein Lauf rot endet.

Noch nicht in dieser Edition

• Das Test-Coverage-Panel ist eine VS-Code-API, und der Projektmappen-Explorer kann keine Badges zeigen. Compare Two History Runs folgt, wenn Abonnenten danach fragen.

Hinzugefügt

• Welche Dateien gezeigt werden. Ein zweites Dropdown in der Symbolleiste der Coverage-Ansicht, neben der Sortierung: alle Dateien, Dateien mit Lücken, ungetestete Dateien oder die Dateien, deren Zahlen sich seit dem vorigen Lauf bewegt haben. Ordner folgen ihren Dateien und behalten ihre eigenen Zahlen. In jeder Stufe.
• Risk hotspots. Unter dem Baum: 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. Community sieht die Anzahl und den schlechtesten Score; die Rangliste ist Pro.
• dotnet test ohne Paket. Run Tests with Coverage liest zuerst die Projektdateien: Wo keine Coverlet referenziert, nutzt der Lauf Microsofts eigenen Collector — --collect:"Code Coverage;Format=cobertura" —, der mit Microsoft.NET.Test.Sdk mitkommt, und sein Bericht wird wie der von Coverlet geladen.
• Generierte .NET-Dateien bleiben außen vor. ignore.generated, standardmäßig an, entfernt *.Designer.cs, *.g.cs, *.generated.cs, *.razor.g.cs, AssemblyInfo, globale Usings, alles unter Migrations/ und unter obj/ aus jeder Summe, jeder Seite und jedem Export. Eine Designer-Datei, die niemand testet, kostet eine Projektmappe nicht mehr ihr Gate.
• Ein fehlgeschlagener Lauf behält die letzte gute Coverage. Mit testRun.skipWhenTestsFail lässt ein Lauf, der mit einem fehlgeschlagenen Test endet, die Coverage auf dem Bildschirm, wie sie war, und sagt es im Output-Bereich. Standardmäßig aus.

Geändert

• Ein Test-Explorer-Lauf wird von selbst gefunden. Ohne jede Konfiguration umfassen die bekannten Namen jetzt den Ordner TestResults/<run>/ jedes Testprojekts, nicht nur den des Arbeitsbereichsordners selbst, und die <user>_<machine>_<date>.cobertura.xml von Microsofts Collector neben der von Coverlet. Eine .NET-Projektmappe, deren Tests in Visual Studio gelaufen sind, zeigt ihre Coverage beim ersten Öffnen; jeder Lauf-Ordner wird geladen, und die Zusammenführung behält für jede Datei das Wort des neuesten Laufs.

Hinzugefügt

• Eine zweite Erweiterung, für Visual Studio 2022 und 2026 — Community, Professional und Enterprise. Derselbe Reader wie in der VS-Code-Edition, sodass derselbe Bericht in beiden Editoren dieselben Zahlen liefert, auf die Stelle genau; und dieselben fuciniCoverage.*-Einstellungen, gelesen aus .vscode/settings.json wie aus VS Codes eigenen Benutzereinstellungen, wenn es auf dem Rechner ist. Sie verwendet nicht Visual Studios eigene Code Coverage: In Visual Studio 2022 ist das eine Enterprise-Funktion, und auf Community und Professional ist dies die einzige Coverage, die die IDE zeigt.
• Im Editor: ein Balken in der Randleiste pro Zeile — rot lief nie, bernstein teilweise, eine Heatmap nach Besuchen — Inline-Trefferzahlen, eine Zeile über jeder Funktion mit ihrer Coverage, Komplexität, ihrem CRAP-Wert und MC/DC, Streifen auf der Bildlaufleiste, ein Hover, der sagt, welcher Zweig nicht genommen wurde, und ein Punkt auf einer Zeile, die Sie seit dem Bericht bearbeitet haben.
• Das Coverage-Fenster (View → Other Windows → Coverage): jede Datei mit ihren Metriken und ein Wert über alle, sortierbar, mit den ungemessenen Dateien darunter; die Statusleisten-Einträge Coverage und File, jeder öffnet die ganze Karte.
• Befehle unter Tools → Coverage Studio, mit Zwei-Tasten-Akkorden nach Ctrl+Shift+U: N/P für die nächste und vorige nicht abgedeckte Zeile, B für die nächste teilweise getestete Entscheidung, R zum Neuladen. Der Watch-Modus lädt neu, wenn sich die Datei ändert, die Ihr Build schreibt.
• Getting Started, die sechs Schritte mit einem Knopf für jeden, in 18 Sprachen; öffnet sich beim ersten Mal von selbst.
• Einstellungen über das Zahnrad in der Symbolleiste des Coverage-Fensters, das die Benutzereinstellungen dieser Edition oder die .vscode/settings.json des Ordners schreibt und die Kommentare einer Datei, die es bearbeitet, erhält.
• Lizenz: in jedem bezahlten Plan enthalten. Ein Rechner, auf dem Coverage Studio für VS Code aktiviert ist, braucht nichts weiter — der Schlüssel wird von selbst gefunden; überall sonst nimmt Tools → Coverage Studio → Licence… den Abonnementcode aus Ihrer Aktivierungs-E-Mail entgegen. Ohne Abonnement wird keine Coverage gelesen: In Visual Studio gibt es keine kostenlose Stufe.

Noch nicht in dieser Edition

• Run Tests with Coverage und das Test-Coverage-Panel sind VS-Code-APIs; der Projektmappen-Explorer kann keine Badges zeigen. Die Annotated-Source-Ansicht, der HTML-Bericht und die Exporte, Check Thresholds, die Fehlerlisten-Einträge, Verlauf und Trend sowie Diff-Coverage folgen in der Reihenfolge, in der Abonnenten danach fragen.

Hinzugefügt

• Ein Walkthrough. Get started with Coverage Studio — unter Help → Welcome → Walkthroughs, und nach der Installation von selbst geöffnet — führt einen neuen Benutzer in sechs Schritten vom Coverage-Bericht zu den Zeilen, die niemand testet, jeder mit einem Knopf für den Befehl, um den es geht. In allen achtzehn Sprachen.
• Die Install-ID wird dort hinterlassen, wo Coverage Studio für Visual Studio sie liest. Die Visual-Studio-Edition prüft den Schlüssel in license.key gegen denselben Fingerabdruck und kann den Zustandsspeicher dieser Erweiterung nicht lesen; bei jeder Aktivierung wird die ID jetzt auch neben dem globalen Speicher der Erweiterung geschrieben, sodass ein in VS Code aktivierter Rechner keine zweite Aktivierung in Visual Studio braucht. Eine zufällige UUID, an nichts gebunden, nie irgendwohin gesendet.

Geändert

• Eine Erstattung beendet das Abonnement. Eine genehmigte Erstattung oder ein Chargeback kündigt das Abonnement jetzt sofort, und sein Aktivierungscode gibt keine Schlüssel mehr aus; Erstattungen gibt es eine pro Kunde. Schlüssel, die schon auf einem Rechner sind, laufen wie bisher bis zu ihrem eigenen Ablauf. Die Erstattungsrichtlinie sagt genau, was geschieht.

Behoben

• Dateinamen in der Coverage-Ansicht sind bei jeder Breite lesbar. Der Name war der einzige Teil einer Zeile, der schrumpfte – in einer gewöhnlichen Seitenleiste auf sieben Zeichen. Er wird jetzt vollständig gezeichnet, und die Metrikspalten, der Score und der Balken schieben sich von links darunter und blenden an der Schnittkante aus, damit eine halbe Zahl nie wie eine ganze aussieht. Jeder Wert steht weiterhin im Tooltip der Zeile.
• Die Markierung „Datei wurde geändert“ hält mit der Datei Schritt. Nach dem Laden folgte sie der ersten Änderung und der ersten Wiederherstellung, danach bewegte sie bis zum nächsten Laden nichts mehr. Jetzt kommt jedes Speichern und jede Änderung auf dem Datenträger an.
• Die Symbolleiste der Coverage-Ansicht bricht ihre Schaltflächenbeschriftungen nicht mehr um. In einer schmalen Seitenleiste bricht die Symbolleiste jetzt zwischen ihren Bedienelementen um, und das Sortierfeld wandert in eine eigene Zeile.
• Das Coverage-Badge ist auch in der Exportauswahl kostenlos. Generate Coverage Badge hat das SVG-Badge schon immer in jeder Stufe geschrieben, während Export Coverage Report… dieselbe Datei in Community verweigerte. Jetzt schreiben beide sie.
• Show Worst-Covered Folders ist wie die beiden anderen Listen lizenziert. In Community ändert sich nichts – dort sind alle drei kostenlos und ungezählt – und auch für keinen bereits ausgestellten Schlüssel.

Hinzugefügt

• Eine unterstützte Mindestversion. Die Erweiterung liest jetzt etwa einmal pro Woche eine kleine signierte Richtlinie von unserem Lizenzserver. Ist ein Build älter als die älteste noch unterstützte Version, halten die Testphase und die kostenlose Stufe an und bitten um ein Update; eine bezahlte Lizenz erfährt das Datum und funktioniert zunächst für eine Schonfrist weiter. Der Abruf sendet nichts über Sie oder Ihre Installation, und eine Installation, die den Server nicht erreicht, wird deshalb nie angehalten. Derzeit ist kein Minimum gesetzt.

Geändert

• Die Lizenz ist ab dieser Version proprietär. Die Erweiterung wurde unter MIT-Bedingungen veröffentlicht, was nie zu einem im Abonnement verkauften Produkt passte. Sie dürfen den veröffentlichten Build im Rahmen Ihres Plans installieren und nutzen, auch kommerziell; Sie dürfen ihn nicht kopieren, verändern, weiterverbreiten oder zurückentwickeln. Was er aus Ihren Daten erzeugt – Berichte, Exporte, Badges – gehört Ihnen, und die frühere Nennungsbedingung entfällt. Eine Kopie einer früheren Version bleibt unter den Bedingungen, mit denen sie kam.
• Die Schaltfläche für Pfadaktionen (⋯) belegt keinen Platz, bis Sie auf eine Zeile zeigen. Die 25 Pixel, die sie in jeder Zeile reserviert hielt, gehen jetzt an den Dateinamen; sie erscheint beim Überfahren direkt hinter dem Namen, und nichts in der Zeile bewegt sich.

Behoben

• LCOV-2-Tracefiles führen jede Funktion einmal auf. FN:<Zeile>,<Endzeile>,<Name> wird so gelesen, wie lcov 2.0 es schreibt – zuvor erschien jede Funktion zweimal, einmal als nie aufgerufen und einmal in Zeile 0 –, und die FNL:/FNA:-Paare von lcov 2.2 werden mitgelesen.
• Ein C++-Template wird nicht mehr als nie ausgeführt gezeichnet, weil eine Instanziierung es nicht war, und eine Funktion voller Makros ist wieder eine Funktion statt einer pro Makro.
• Die Einwilligungstexte sagen, was die Installation tatsächlich sendet: keine monatliche Seite Ihres Quellcodes, und Ihre Nutzungszusammenfassung trägt den Anforderungscode, auf den Ihr Schlüssel ausgestellt wurde.

Hinzugefügt

• Bedingungsüberdeckung ist eine eigene Metrik. a && b ist eine Entscheidung und zwei Bedingungen, und eine Suite kann beide Zweige nehmen, ohne b je falsch zu sehen. Sie hat nun eine eigene Zeile, Spalte, Ausgabe, ein eigenes Abzeichen, ein Gewicht in der Bewertung (3, zwischen Zweigen und MC/DC) und ein eigenes Gate – gelesen aus BullseyeCoverage, einem TRACE32-cond-Export und GCC 14 mit -fcondition-coverage.
• Mutanten, dort wo sie sind. PIT- und Stryker-Berichte werden Mutant für Mutant gelesen: die überlebenden werden in der jeweiligen Zeile im Editor markiert, mit der Änderung und den Tests, die sie ausgeführt haben, im Tooltip, und im HTML-Bericht sowie im annotierten Quellcode aufgeführt.
• Welche Tests diese Zeile ausgeführt haben. coverage.py mit --show-contexts und OpenCover mit -coverbytest sagen beide, welche Tests eine Zeile erreicht haben; der Tooltip mit der Trefferzahl nennt sie.
• Der Teil einer ausgeführten Zeile, der nie lief, wird im Editor eingefärbt, und C- und C++-Funktionen erhalten eine Komplexität und einen CRAP-Wert, gezählt aus den Zweigdaten, die llvm-cov ohnehin mitbringt.
• JaCoCo-, Cobertura- und Coverlet-Projekte laden beim ersten Öffnen, ohne Einstellung – auch dort, wo Maven, Gradle und dotnet test standardmäßig schreiben.
• Jede Metrik neben jeder Datei, bei jeder Breite, geordnet nach ihrem Gewicht in Ihrer Bewertung, wobei Nichtpassendes scrollt statt zu verschwinden – und eine Zahl am Coverage-Symbol, wenn ein Tracefile neu geladen wird, während Sie woanders hinsehen.
• Ein Vorabkanal, für den Sie sich melden können, und eine Schaltfläche in der Editor-Titelleiste, die die Überdeckungsdarstellung abschaltet und genau das zurückbringt, was sie hatte.

Geändert

• Bullseye und TRACE32: Zweigüberdeckung enthält keine Bedingungen mehr. Die Entscheidungen sind Zweigüberdeckung, die Bedingungen Bedingungsüberdeckung – der Zweigwert eines solchen Projekts ändert sich also, und mit ihm die zusammengesetzte Bewertung. Setzen Sie whmWeights.conditions auf 0 für die Bewertung wie zuvor.
• Die kostenlose Community-Stufe hat ein Wochenkontingent: je fünf pro Woche der gezählten Aktionen, wo es zwanzig pro Tag waren, und an der Grenze werden ein Abonnement oder ein 7-Tage-Pass angeboten. Eine bereits genutzte Installation behält ihre alten Grenzen 30 Tage und wird einmal darauf hingewiesen, mit dem Datum.
• Testphase und kostenlose Stufe führen ein Nutzungsregister beim Lizenzserver: ein Hash der Maschinen-ID von VS Code, die Edition, der Tag des Evaluierungsbeginns und die Zähler der gemessenen Aktionen – nichts sonst, nie bei einer bezahlten Lizenz und nie mit Wartezeit. Der Telemetrie-Tausch ist jetzt einmalig 30 Tage.
• Die monatliche Seite Quellcode ist weg – sie wird für niemanden mehr erhoben, gespeichert oder gesendet, und eine von einer früheren Version aufbewahrte wird beim ersten Start dieser gelöscht.

Behoben

• Die Heatmap liest sich auf einem dunklen Theme richtig herum. Ihr Verlauf ging von Blassgelb zu Dunkelbraun, sodass die heißeste Schleife den blassesten Balken hatte. Ein dunkles Theme hat jetzt einen eigenen Verlauf, von gedämpftem Oliv zu kräftigem Orange.
• Der MC/DC-Hover zeigt seine Details wieder, und eine llvm-cov-Entscheidung zählt ihre Bedingungen korrekt. Das aktuelle VS Code faltete den Hover zu einer einzigen Zeile zusammen; und (a && b) || c wurde mit einer Bedingung bei 100 % aufgeführt, unter einer Überschrift, die zu Recht 2 von 3 Paaren nannte.
• C++-Funktionen heißen so, wie Sie sie geschrieben haben: clamp_to<int> und gearbox::next_gear statt des Linker-Namens ??$clamp_to@H@@YAHHHH@Z, für llvm-cov, lcov und gcov.
• Die Zeilenzahlen von Istanbul stimmen mit nyc überein, dotnet-coverage-XML wird gelesen, SimpleCov-:nocov:-Zeilen werden ausgeschlossen statt als fehlerhaft behandelt, und ein Bericht, der nur eine Zusammenfassung enthält, behält seine Zahlen, in welcher Reihenfolge die Berichte auch gelesen werden.
• Multi-Root-Arbeitsbereiche: Der HTML-Bericht nennt einen Ordner nicht mehr doppelt, die Coverage-Ansicht überschreibt einen Arbeitsbereichsordner mit seinem Namen, und eine pathRemap-Regel darf neben ${workspaceRoot} auch ${workspaceFolder} verwenden.

Hinzugefügt

• Alles, was ein Bericht enthält, wird angezeigt. Funktionsaufrufe, Objektcode und ein Mutationsscore erhalten eine Spalte in der Coverage-Ansicht, im HTML-Bericht und in den CSV- und Markdown-Exporten, eine Zeile in den Karten der Statusleiste und ein Badge im annotierten Quelltext — und eine Metrik, die ein Bericht nicht enthält, wird weggelassen, statt als null ausgegeben zu werden.
• Komplexität und CRAP. Wo ein Bericht die zyklomatische Komplexität enthält (OpenCover, JaCoCo, Clover, Cobertura), erhält jede Funktion einen CRAP-Wert in ihrer CodeLens, eine Datei erhält einen Max CRAP, der zur Methode verlinkt, und der HTML-Bericht listet die Riskiest Methods auf.
• Mehr aus jedem Format: benannte Zweigarme, ausgeschlossene Zeilen, Spaltenbereiche innerhalb einer Zeile, Werkzeug, Version und Datum des Berichts sowie die Warnungen, die ein Werkzeug hineingeschrieben hat.
• Optionale Gewichte für Objektcode und den Mutationsscore in der zusammengesetzten Bewertung, beide 0, solange Sie sie nicht setzen.

Geändert

• Die Standardschwellen liegen nicht mehr bei 100 %. Eine Schwelle, die Sie nicht gesetzt haben, steht jetzt für Zeilen 80, Funktionen 80, Regionen 75, Zweige 70 und zusammengesetzte Bewertung 75, ohne Schranke für MC/DC, Instanziierungen, Funktionsaufrufe oder Objektcode — das, was sich von einem gewöhnlichen Projekt verlangen lässt. fuciniCoverage.threshold.profile: "safety" setzt jede Schranke wieder auf 100, genau wie zuvor, und eine Schwelle, die Sie selbst gesetzt haben, hat Vorrang vor beiden Profilen. Wenn Sie sich auf die alten Standardwerte verlassen haben, werden Sie milder beurteilt, bis Sie safety auswählen; eine Installation, die schon zuvor lief, wird einmalig darauf hingewiesen, mit einer Schaltfläche, die das Profil setzt.
• Eine Metrik ohne Schranke zeigt einen neutralen Strich in den Karten statt eines Häkchens oder Kreuzes, und das Einstellungspanel zeigt die Vorschau des Urteils mit den tatsächlich geltenden Schranken.

Behoben

• Abdeckung in einem Puffer mit ungespeicherten Änderungen stimmt wieder. Ein Lauf, der geladen wurde, während eine Datei ungespeicherte Änderungen hatte, setzte jede Markierung, jeden Hover und jede CodeLens um so viele Zeilen versetzt, wie die Änderungen sie verschoben hatten. Die Änderungen werden jetzt aus der Datei auf der Festplatte rekonstruiert, und eine oberhalb einer Zeile eingefügte ganze Zeile zählt diese Zeile nicht mehr als bearbeitet.
• Zusammenführungen und wiederholte LCOV-Datensätze werden richtig addiert. Eine neuere Tracefile behält nicht mehr die Zweig- und MC/DC-Zusammenfassungen des älteren Laufs, und eine in einer Tracefile zweimal aufgeführte Datei wird so zusammengefasst, wie genhtml es tut.
• Der Lizenzschlüssel bleibt auf seinem Rechner. Settings Sync trägt ihn nicht mehr auf andere Installationen, wo er die Abdeckung blockierte; ein abgelaufener Business-, Enterprise- oder Pro-Plus-Schlüssel erneuert sich bis zu 45 Tage nach Ablauf selbst.
• Entfernte Tracefiles werden sorgfältiger abgerufen. remote.headers bleiben über Weiterleitungen hinweg bei ihrem Ursprung, ein Abruf gibt nach 30 Sekunden auf, eine Anmeldeseite wird abgelehnt statt zwischengespeichert, und ein offline geöffnetes Fenster lädt die zuletzt heruntergeladene Kopie. Die Selbstaktualisierung installiert nur die eigene Edition.
• Parser: llvm-cov-Zeilenzähler stimmen mit llvm-cov show überein, OpenCover-Entscheidungen aus verschiedenen Methoden überschreiben einander nicht mehr, xccov, TRACE32 und EMMA behalten ihre Zeilenwerte, Cobertura-Klassen in einer Datei sind eine Datei, JaCoCo-Sammelberichte werden gelesen, und die Pfadzuordnung löst .. auf und vergleicht ganze Segmente.
• Im Editor: der Verlauf wird pro Arbeitsbereich geführt, Markierungen bleiben auf echten Dateien statt auf der HEAD-Seite eines Diff-Editors, Zeilen hinter dem Dateiende werden nicht gemalt, Explorer-Badges unter Windows funktionieren für C:\…-Pfade, und große Läufe sind schneller nachzuschlagen.

Hinzugefügt

• Diagnosebericht senden. Die Benachrichtigungen zu einem fehlgeschlagenen Laden, Fernabruf, Zusammenführen, Verlaufsvergleich oder Chat bieten ihn an. Er zeigt genau das JSON, das gesendet würde, mit optionaler 4-KB-Dateiprobe, Kommentar und Antwortadresse, und sendet nichts, bevor Sie auf Senden klicken.
• Fehlerberichte. Ein FUCINI_*-Fehler wird ohne Dateiinhalt, Pfade oder Namen gemeldet, wenn die Telemetriestufe von VS Code all oder error ist. Drei Protokollzeilen haben eigene Codes: FUCINI_REMOTE_002, FUCINI_REMOTE_003 und FUCINI_GITDIFF_002, jeder im Benutzerhandbuch beschrieben.

Geändert

• Jeder Abdeckungsprozentwert hat zwei Nachkommastellen, abgeschnitten statt gerundet: 87.43%, und 100.00% nur, wenn die Abdeckung genau 100 ist.
• Schwellen entscheiden auf dem exakten Wert. Bisher wurde jeder Prozentwert zuerst auf eine ganze Zahl gerundet, sodass 89,6 % eine 90-%-Schwelle bestand. Ein Projekt, das nur durch Rundung bestand, zeigt jetzt NON-COMPLIANT, bis seine Abdeckung die Schwelle wirklich erreicht.
• Telemetrie ist täglich. Jede Installation sendet auf der VS-Code-Telemetriestufe all täglich eine kleine Lizenzmeldung; mit eingeschaltetem telemetry.enabled geht die Nutzungszusammenfassung täglich statt monatlich hinaus. Installationen, die Funktionen für Telemetrie freigeschaltet haben, werden gefragt, bevor sich ihre Bedingungen ändern.

Hinzugefügt

• Die Coverage-Ansicht zeigt ein verfügbares Update an – und zwar dauerhaft. Eine Leiste über dem Lizenzbanner nennt die neue Version neben Ihrer eigenen, mit denselben drei Schaltflächen wie die Update-Benachrichtigung: „Herunterladen & installieren“, „Änderungsprotokoll anzeigen“ und „Diese Version überspringen“. Das Symbol der Ansicht in der Aktivitätsleiste trägt zusätzlich ein Badge, sodass es auch bei geschlossener Ansicht auffällt. Die Benachrichtigung erschien nur einmal, bei der automatischen Prüfung, und ein Klick irgendwo anders blendete sie bis zur nächsten Prüfung einen Tag später aus; die Leiste bleibt, bis das Update installiert oder übersprungen oder fuciniCoverage.update.checkForUpdates ausgeschaltet ist, und übersteht auch ein Neuladen des Fensters.

Geändert

• Die kleinen Pings gehen höchstens einmal am Tag und gebündelt raus. Ein Update, eine Lizenzänderung, ein neues Coverage-Format und eine Datei, die sich nicht einlesen ließ, waren bisher je ein eigener Ping, gesendet, sobald sie auffielen — und auf manchen Installationen in jeder Sitzung erneut: Ein entzogener Platz meldete seinen Entzug bei jedem Start, und der Wechsel zwischen Arbeitsbereichen mit unterschiedlichen Formaten meldete jedes Mal eine „neue“ Formatliste. Sie werden jetzt gesammelt und als ein Ping gesendet, höchstens einmal am Tag. Ein Tag ohne Neuigkeiten sendet nichts.
• Gemeldet wird nur, was sich tatsächlich geändert hat. Eine Lizenz, die sich innerhalb des Tages ändert und wieder zurückwechselt, meldet nichts, und die Formate sind alle, die die Installation je geladen hat, statt nur die des letzten Arbeitsbereichs. Der Installations-Ping und die Deinstallationsmeldung gehen weiterhin sofort raus, und es wird nichts Neues erfasst.
• VS Codes eigener Telemetrie-Schalter gilt jetzt auch für die kleinen Pings. Steht telemetry.telemetryLevel auf off, wird für den täglichen Ping nichts gesammelt und nichts gesendet; bisher richteten sich nur die monatliche Zusammenfassung und die Entfernungsmeldung danach. Der einmalige Installations-Ping bleibt unverändert.
• Ein Monat, der endet, während der Editor ruht, wird trotzdem gemeldet. Die monatliche Zusammenfassung wurde nur nach dem Laden von Coverage geprüft, sodass eine Installation, die nicht mehr genutzt wurde, ihren letzten Monat nie sendete. Jetzt wird sie außerdem stündlich geprüft, solange VS Code geöffnet ist — weiterhin nur bei eingeschalteter Telemetrie und weiterhin höchstens einmal alle 30 Tage.

Behoben

• Ein vom Server abgelehnter Ping gilt nicht mehr als gesendet. Jede Antwort des Servers, auch ein Fehler, galt als Zustellung, sodass ein abgelehnter täglicher Ping verlor, was er gesammelt hatte, und ein abgelehnter Installations-Ping nicht erneut versucht wurde. Jetzt zählt nur eine erfolgreiche Antwort; ein abgelehnter täglicher Ping oder eine abgelehnte monatliche Zusammenfassung bleibt erhalten und wird einen Tag später erneut versucht.

Geändert

• Jede Evaluierung bekommt einmalig frische 14 Tage. Beim ersten Start dieses Releases öffnet sich die Testphase auf jeder Pro-Installation ohne bezahlte Lizenz wieder — ob sie längst abgelaufen war oder noch ein paar Tage übrig hatte — und läuft ab diesem Tag 14 Tage. Ein kurzer Hinweis teilt das mit, wenn es geschieht. Eine bezahlte Lizenz bleibt unberührt, und die Community-Edition, die keine Testphase hat, ist unverändert.
• Eine bezahlte Lizenz zeigt „Aktiviert“, in Grün. Der Lizenzhinweis zeigte einem Abonnenten bisher „Aktiviert – noch 30 Tage“. Ein Abonnement-Schlüssel läuft bis zum Ende des bezahlten Zeitraums und wird mit ihm verlängert, also hätte dieser Countdown nie aufgehört, sich wie eine bald ablaufende Testphase zu lesen. Die Überschrift sagt jetzt einfach Aktiviert, das Datum steht in den Details als „Gültig bis“, und der Countdown kehrt nur in der letzten Woche vor Ablauf eines Schlüssels zurück, neben dem Hinweis auf die baldige Verlängerung, der schon da war.

Hinzugefügt

• „Enter Subscription Code“ — und nichts weiter wird gefragt. Plan wählen, den Code aus Ihrer Kaufbestätigung einfügen, bestätigen — und Ihr Lizenzschlüssel wird für Sie ausgestellt und eingetragen. Bislang führte der einzige Weg von innerhalb des Editors über den Evaluierungsfragebogen — Name, E-Mail, Kontotyp, Firma, eine Umfrage —, und das ist das falsche Formular für jemanden, der schon gekauft hat. Der andere Weg war der vscode://-Link in der E-Mail, und davor zurückzuscheuen ist vernünftig und nicht ängstlich: Ein solcher Link kann von jeder Seite ausgelöst werden, die Sie besuchen, und genau deshalb verlangt die Aktivierung eine Bestätigung. Der Befehl steht in der Befehlspalette, und er ist eine Schaltfläche im Lizenzhinweis des Coverage-Panels und im Aktivierungsdialog — in jedem Zustand, denn eine Lizenz wandert zwischen Rechnern, und mitten in der Testphase zu kaufen ist der gewöhnliche Fall und nicht die Ausnahme.
• Ein Weg zu den Tarifen aus der Testphase heraus. Die Preisseite war von den Bildschirmen der kostenlosen Stufe aus erreichbar, aber nicht vom Aktivierungsdialog und nicht vom Lizenzhinweis — der einen Stelle, auf die jemand wirklich schaut, der „3 Tage übrig“ liest. Diesem Leser wurden ein Fragebogen und ein Hinweis auf settings.json angeboten, und kein Preis.

Geändert

• Aktivierungsdialog und Lizenzhinweis beginnen nicht mehr mit FCK1. Beide führten früher mit Ihrem Anforderungscode und „den Schlüssel in settings.json einfügen“, und das ist der Weg für den Fall, dass unser Lizenzserver überhaupt nicht erreichbar ist. Zuerst gezeigt, las es sich als die Anleitung — also wurde ein Kunde mit einem Abonnement-Code FCB1… zu „Enter Activation Key“ geschickt, dem einen Feld, das ihn sicher ablehnt. Beides ist weiterhin da, unterhalb der Wege, die zu jemandem passen, der gekauft hat, und beschrieben als das, was es tatsächlich ist.

Behoben

• „Request Activation Key“ ist jetzt wirklich ein Befehl. Ihre Kaufbestätigung — und die Aktivierungsseite, in jeder Sprache — sagt Ihnen, dass Sie, falls der Ein-Klick-Link Ihr Mailprogramm nicht übersteht, Fucini Coverage: Request Activation Key über die Befehlspalette ausführen, Ihren Plan wählen und Ihren Code einfügen können. Dieser Name gehörte der Titelleiste des Panels und dem Link selbst, nie einem Befehl, also stand in der Palette nichts darunter — und die dem Namen nach nächstliegende Übereinstimmung, Enter Activation Key, nimmt den Schlüssel FCK1…, den unser Server ausstellt, und nicht den Code FCB1…, den Ihre E-Mail trägt. Der Anleitung zu folgen führte Sie in genau das eine Feld, das Ihre Eingabe sicher ablehnt. Jetzt ist es ein echter Befehl.
• Der Aktivierungsdialog bietet Lizenz anfordern… auch dann an, wenn eine Testphase oder ein Schlüssel noch gültig ist. Bisher wurde er zurückgehalten, bis eines von beiden abgelaufen war, mit der Begründung, eine funktionierende Installation habe keinen Grund, den Lizenzserver zu kontaktieren. Mitten in der Testphase zu kaufen ist aber der gewöhnliche Fall und nicht die Ausnahme, und wer sich in dieser Lage befand, hatte vom Dialog aus keinen Weg zu dem Feld, in das sein Code gehört: Die beiden verbliebenen Schaltflächen verlangten einen Schlüssel, den erst das Einlösen des Codes hervorbringt.

Hinzugefügt

• Eine Palette für Farbenblinde. Setzen Sie colorScale.preset auf colorblind, und Coverage wird in Zinnoberrot, Orange und Blau (die Okabe-Ito-Palette) statt Rot, Bernstein und Grün gezeichnet — Verlauf, Randleisten, Zeilenhervorhebung, Explorer-Badges und die Markierungen seit dem letzten Lauf gleichermaßen. Eine selbst gesetzte Farbe hat Vorrang.

Hinzugefügt

• Abdeckung nach Test filtern, in der eigenen Test-Coverage-Ansicht von VS Code. Nennt eine Tracedatei ihre Tests — die TN:-Abschnitte von lcov —, wird jeder Test zu einem Eintrag unter Fucini Coverage im Test Explorer, jede Datei in der Test-Coverage-Ansicht listet die Tests auf, die darin etwas ausgeführt haben, und die Auswahl eines Tests zeigt die Zeilen, die genau dieser Test erreicht hat.
• ${command:…} in Pfadeinstellungen. ${command:cmake.buildDirectory}/coverage.info folgt dem gerade gewählten CMake-Kit. Der Befehl läuft vor jeder Suche, höchstens fünf Sekunden lang und nur in einem vertrauenswürdigen Arbeitsbereich; schlägt er fehl, bleibt die Variable wie geschrieben stehen, und die Ausgabe sagt, warum.
• Ein Schnellstart in 30 Sekunden und ein Vergleich mit den Alternativen stehen jetzt am Anfang der Marketplace-Seite und der Startseite.

Behoben

• Eine Tracedatei, die eine Datei einmal pro Test erfasste, zählte sie auch einmal pro Test. Die Einträge werden jetzt pro Tracedatei zusammengezählt, so wie genhtml sie liest: Die Datei zählt einmal in den Summen, und mit mehreren geladenen Tracedateien gehen die Zeilen keines Tests verloren.

Behoben

• Die Installations-ID wird jetzt gespeichert, bevor irgendetwas sie verwendet. 0.2026.72 Build 2 hat verhindert, dass die ID bei jedem Aufruf neu ermittelt wird, doch beim Start wartete weiterhin nichts darauf, dass sie geschrieben war. Ein Fenster, das kurz nach dem Öffnen geschlossen wurde, konnte sie also immer noch verlieren — und mit ihr den Maschinen-Fingerabdruck, an den ein Aktivierungsschlüssel gebunden ist. Der Start wartet jetzt.
• Der Wechsel von Pro zu Community lässt Ihren Aktivierungsschlüssel gültig. Jede Edition hat ihren eigenen Erweiterungsspeicher, deshalb begann Community mit einer neuen Installations-ID und einem neuen Fingerabdruck, während der Schlüssel in Ihren Einstellungen — auch der, den der Wechsel gerade für die kostenlose Freischaltung angefordert hatte — an den alten gebunden war. Der Wechsel reicht die ID jetzt weiter.

Sicherheit

• Updates von fucini.software sind signiert und werden vor der Installation geprüft. Jede .vsix im Update-Feed trägt einen SHA-256-Hash und eine Ed25519-Signatur mit einem Schlüssel, der nie auf dem Webserver liegt. Der eingebaute Updater und der Wechsel zu Community prüfen beides gegen die heruntergeladene Datei und lehnen alles andere ab — die Fehlerseite eines Proxys, einen abgebrochenen Download, einen älteren Build aus einem Cache oder eine Datei, die nicht von uns stammt. HTTPS allein deckt das nicht ab: Ein Unternehmensproxy mit TLS-Inspektion signiert jede Verbindung, die er sieht, neu.
• Jedes Release hat einen eigenen Dateinamen. Der Update-Feed verweist jetzt auf eine versionierte .vsix statt auf eine Datei, die bei jedem Release überschrieben wurde, sodass ein Cache, der Cache-Control ignoriert, den Build des Vormonats nicht als den aktuellen ausliefern kann. Die Links auf der Download-Seite bleiben unverändert.

Hinzugefügt

• Zu den Verzweigungen springen, die nur in eine Richtung getestet wurden. Next Partly-Tested Decision und ihr vorheriges Gegenstück laufen die Entscheidungen ab, von deren Zweigen einige ausgeführt wurden und andere nie. Das ist die Lücke, die eine Navigation über ungetestete Zeilen nicht zeigen kann: Eine Zeile, deren Anweisung ausgeführt wurde, gilt als abgedeckt und bleibt es, wie viele ihrer Zweige auch nie genommen wurden — if (a && b), einmal mit falschem a erreicht, ist zu 100% zeilenabgedeckt und halb getestet. Ein Halt je Entscheidung statt je Zweig, denn die Zweige eines if/else können Seiten auseinanderliegen, und zum fünften Zweig eines switch zu springen sagt weniger als zum switch selbst. Entscheidungen, die kein Zweig je erreicht hat, bleiben den Befehlen für ungetestete Zeilen überlassen, die dort ohnehin halten — und eine Datei, deren Bericht überhaupt keine Verzweigungen enthält, sagt das, statt zu behaupten, jede Entscheidung sei in beide Richtungen getestet.
• Reload Coverage liest erneut, was bereits geladen ist. Bei ausgeschalteter Überwachung führte der einzige Weg zu frischen Zahlen nach einem erneuten Testlauf über Load Coverage, das die Suche neu ausführt und mit einem anderen Satz zurückkommen kann als dem auf dem Bildschirm. Dieser Befehl liest genau das erneut, was jetzt geladen ist, einschließlich von Hand ausgewählter Tracedateien, die die Suche nie wieder finden würde.
• Copy Coverage Summary bringt den Lauf in eine Markdown-Tabelle. Die am schlechtesten abgedeckte Datei zuerst, mit einer Summenzeile, bereit zum Einfügen in einen Pull Request. Die Spalten für Verzweigungen und MC/DC erscheinen nur, wenn im Lauf etwas sie gemessen hat: Eine Spalte aus Gedankenstrichen liest sich als null Abdeckung statt als nicht gemessen, und das ist das Gegenteil der Wahrheit.

Behoben

• Die Installations-ID konnte sich zwischen Sitzungen ändern — und genau aus ihr wird der Lizenz-Fingerabdruck gebildet. Sie wurde bei jedem Aufruf neu ermittelt und gespeichert, ohne dass jemand auf den Schreibvorgang wartete; ein zweiter Aufruf oder ein kurz nach dem Start geschlossenes Editorfenster konnte deshalb eine neue erzeugen. Eine ID, die sich ändert, ist ein Aktivierungsschlüssel, der nicht mehr passt — und sie blähte jede pro Installation gezählte Zahl auf. Sie wird nun einmal je Sitzung festgelegt und gespeichert, bevor irgendetwas sie verwendet. Build 2.

Hinzugefügt

• Herkunft auf Zeilenebene. Sind mehrere Tracedateien geladen, endet der Hover mit der Trefferzahl nun mit Abgedeckt von: und den Berichten, die auf dieser Zeile einen Treffer verzeichnet haben — und ein Klick auf eine Tracedatei-Zeile in der Ansicht Coverage hebt jetzt die Zeilen hervor, die sie beigesteuert hat, in jedem offenen Editor, so wie sie bisher schon die von ihr gemessenen Dateien hervorgehoben hat. Das ist die eine Frage, die ein zusammengeführter Lauf beantworten kann und ein einzelner Bericht nicht: zwei Tracedateien, die dieselbe Datei messen, sind sich über deren Zeilen uneins, und bisher hat die Zusammenführung diese Uneinigkeit eingeebnet, ohne sie je zu zeigen. Zusammengeführt wird weiterhin dateiweise — der neueste Bericht gewinnt eine gemeinsame Datei vollständig —, deshalb wird die Herkunft je Zeile vor der Zusammenführung indiziert. Nur abgedeckte Zeilen zählen: ein Bericht, der eine Zeile als 0 festgehalten hat, hat sie nicht abgedeckt.
• Der TN:-Eintrag von lcov wird endlich gelesen. Eine Tracedatei, die ihre Suite benennt — TN:integration —, erscheint überall dort, wo Herkunft genannt wird, als coverage.info (integration), und der Name übersteht einen Export zurück nach lcov, statt leer geschrieben zu werden. Die meisten Werkzeuge schreiben TN: leer und ändern sich nicht; die, die ihn füllen, sind genau jene, deren Tracedateien zusammengeführt werden, und dann sagt allein der Name, welche welche ist.
• fuciniCoverage.lineHighlight färbt die Zeilen selbst. off | uncovered | heatmap, standardmäßig aus: eine durchscheinende Färbung hinter jeder nicht und jeder teilweise abgedeckten Zeile, im Modus heatmap auch hinter jeder ausgeführten, umso wärmer, je öfter sie lief. Eine eigene Einstellung statt eines vierten Werts von editorGutter.mode, weil beide in unterschiedlichen Kombinationen gewünscht werden: die Lücken gefärbt bei sauberem Randstreifen, oder Balken ohne Farbe hinter dem Code. Durchscheinend, weil sie unter dem Text liegt, und sie färbt die Lücken statt der abgedeckten Zeilen, aus demselben Grund wie der Randstreifen.
• fuciniCoverage.overviewRuler entscheidet allein über den Streifen in der Bildlaufleiste. follow (Standard) verhält sich wie bisher: ein Streifen überall dort, wo der Randstreifen einen Balken für nicht oder teilweise abgedeckt zeichnet, und nie für die Heatmap. uncovered zeichnet ihn auch bei ausgeschaltetem editorGutter.mode — eine Karte der Lücken entlang der Bildlaufleiste und nichts neben dem Code. off behält die Balken und lässt den Streifen weg. Zuvor war das Lineal fest an den Randstreifen gekoppelt, diese beiden Kombinationen gab es also nicht.

Behoben

• Eine Tracedatei, die sich nicht lesen lässt, sagt jetzt, als was sie gelesen wurde. „…ist nicht wohlgeformt“ ließ offen, ob die Datei überhaupt als das Format erkannt wurde, für das man sie hält — und ein von VectorCASTs Parser abgelehntes Cobertura-Dokument ist ein anderes Problem als ein wirklich abgeschnittenes. Die Meldung endet nun mit Sie wurde als cobertura gelesen., wenn ein Parser die Datei beansprucht hat. Hat es keiner getan, wird nichts angehängt: „nicht in einem Format, das diese Erweiterung liest“ sagt das bereits vollständig.

Behoben

• Der Hinweis auf veraltete Daten im Tooltip der Statusleiste zeigt wieder sein Uhrsymbol statt des Textes $(history). Der Hinweis, der sagt, dass die Zahlen darunter einen älteren Stand der Dateien beschreiben, trägt dasselbe $(history)-Zeichen wie die Statusleiste selbst. In der Statusleiste wird es als Uhrsymbol gezeichnet, weil StatusBarItem.text Symbole von sich aus einsetzt; der Tooltip ist ein MarkdownString, der das mit supportThemeIcons erst anfordern muss und es nie tat — so begann ausgerechnet die Zeile, die erklärt, warum den Zahlen nicht zu trauen ist, mit einem Stück roher Syntax. Der Tooltip fordert es jetzt an.

Hinzugefügt

• Der eigene Gutter des Editors kann jetzt nicht abgedeckte Zeilen zeigen, oder eine Heatmap der Trefferzahlen. Standardmäßig zeigt er weiterhin nur Befunde — MC/DC-Balken, Seit-letztem-Lauf-Dreiecke, Punkte auf bearbeiteten Zeilen —, und die farbcodierte Ansicht einer ganzen Datei bleibt die Annotated Source. fuciniCoverage.editorGutter.mode schaltet mehr hinzu: 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; heatmap legt zusätzlich einen warmen Farbton auf jede ausgeführte Zeile, umso heißer, je öfter sie lief. Choose Editor Gutter Mode... wechselt zwischen den dreien aus der Palette oder dem Statusleisten-Menü. Die README behauptete bisher rundheraus „native Gutter“; jetzt sagt sie, was tatsächlich da ist.
• Inline-Trefferzahlen. fuciniCoverage.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.
• ${env:NAME}, ${config:section.key}, ${userHome} und ${workspaceFolderBasename} in jeder Pfadeinstellung, neben dem ${workspaceFolder}, das es schon gab. 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.
• Ein coverageFile.paths-Eintrag darf eine http(s)://-URL sein. Das Artefakt wird bei jedem Laden in den Speicher der Erweiterung geholt und von dort geladen; die Coverage-Ansicht nennt die URL, nicht den Cache-Pfad. Jeder Abruf ist bedingt (ETag / Last-Modified), sodass ein erneuter Abruf eines unveränderten Artefakts nichts herunterlädt, und schlägt ein Abruf fehl, wird stattdessen die zuletzt heruntergeladene Kopie geladen und der Grund steht in der Ausgabe. fuciniCoverage.remote.headers fügt Name: value-Header mit expandierten Variablen hinzu — Authorization: Bearer ${env:CI_TOKEN} hält das Token aus der settings.json heraus —, und fuciniCoverage.remote.refreshMinutes ruft nach einem Zeitplan erneut ab. Hängen Sie #lcov.info (oder einen anderen Dateinamen) als URL-Fragment an, wenn die URL selbst nicht auf einen endet, damit das Format bekannt ist.
• Das Laden und Generate Full HTML Report zeigen einen Fortschritt und lassen sich abbrechen. 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 (Lesen, dann Prüfen der Quellen); ein kleinerer lässt wie bisher nur die Statusleiste kreisen. Ein Abbruch lässt den vorherigen Lauf geladen und sagt das. Der HTML-Bericht tut dasselbe je gerenderter und geschriebener Seite.
• Zwei weitere Gründe zum Neuladen. Ein absoluter coverageFile.paths-Eintrag außerhalb des Arbeitsbereichs — ein Build-Baum neben dem Checkout, ein Bazel-Ausgabestamm — wird jetzt ebenfalls abgefragt, sodass eine Datei, die dort erscheint, nachdem das Fenster geöffnet wurde, geladen wird, statt nie wieder angesehen zu werden; der Watcher sah immer nur den Arbeitsbereich. Und fuciniCoverage.watch.reloadAfterTasks nennt Aufgaben (ein label aus der tasks.json, oder source: name, wie die Liste von Run Task es zeigt, z. B. npm: test), 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 Lauf, der einen per Symlink eingebundenen Ausgabebaum ersetzt, ein Bericht auf einer Netzwerkfreigabe, ein Coverage-Schritt, der seine Datei nachbearbeitet.
• Multi-Root-Arbeitsbereiche. Jeder Ordner eines Arbeitsbereichs wird jetzt nach seinen eigenen Regeln erkannt: coverageFile.defaultLocation, coverageFile.paths, pathRemap, ignore, watch.*, remote.*, badge.*, die Berichtsverzeichnisse, gitDiff.*, problems.perLine, editorGutter.mode und hitCounts.inline werden je Ordner gelesen, sodass die eigene .vscode/settings.json eines Ordners oder sein .code-workspace-Eintrag gilt; ${workspaceFolder} meint den eigenen Ordner des Eintrags; in allen Ordnern gefundene Tracedateien verschmelzen zu einem Lauf, und die Coverage-Ansicht gruppiert die Dateien nach Ordner. ${workspaceRoot} in einer pathRemap-Regel versucht zuerst den eigenen Ordner der Tracedatei, dann die anderen. Alles, was einen einzelnen Ordner braucht — die Dateidialoge, die Berichts- und Badge-Ausgabe, Git-Metadaten, Run Tests with Coverage — nimmt den des aktiven Editors, und bei mehreren Ordnern und ohne Editor fragt der Testlauf, welchen. Ein zum Arbeitsbereich hinzugefügter oder daraus entfernter Ordner lädt die Coverage von selbst neu. Bisher nahmen zwölf Stellen den ersten Ordner, und ein zweiter Stamm bekam für alles die falsche Basis.
• Der Lauf wird in VS Codes eigene Test-Coverage-Ansicht veröffentlicht. Mit fuciniCoverage.testCoverage.publish (standardmäßig an) geht jeder geladene Lauf auch in das native Test-Coverage-Panel, seine Prozentzahlen je Datei im Explorer und den editoreigenen Schalter „Show Inline Coverage“ — Zeilen, Zweige und Funktionen, mit bei Bedarf geladenen Details. 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.
• Passen Dateien nicht, wird eine Pfad-Remap-Regel vorgeschlagen. 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. Ohne den Klick wird nichts geschrieben.
• fuciniCoverage.ignore: Dateien, die nie zählen. Eingebundene Fremdbibliotheken (vendored), generierte oder Drittanbieter-Dateien (vendor/**, **/*.generated.ts, build/**) werden beim Laden aus dem Lauf entfernt, sodass Coverage-Ansicht, Statusleiste, Schwellenwerte, Badges, CodeLens, Verlauf und Exporte alle ohne sie zählen; das Ladeergebnis sagt, wie viele weggelassen wurden, und die Ausgabe nennt sie. Muster passen auf den arbeitsbereichsrelativen und den absoluten Pfad; ein Muster ohne / passt auf einen Ordner- oder Dateinamen in beliebiger Tiefe, wie in .gitignore. Für ganze Dateien — Zeilen innerhalb einer Datei verwenden weiterhin die eigenen Ausschlussmarkierungen des Werkzeugs.
• Problems-Einträge je Zeile, opt-in. fuciniCoverage.problems.perLine (off, uncovered oder uncoveredAndPartial; standardmäßig aus) setzt eine Informations-Diagnose auf jeden zusammenhängenden Block von Zeilen, die nie liefen — eine vierzigzeilige tote Funktion ist ein Eintrag, nicht vierzig —, und im zweiten Modus auf jede Zeile, deren Zweig nie genommen wurde. Nur für geöffnete Dokumente, damit ein Lauf mit zweitausend Dateien das Panel nicht fluten kann; die Einträge folgen ihren Zeilen, während der Puffer bearbeitet wird, und verschwinden, wenn das Dokument geschlossen wird. Der Eintrag je Datei hinter problems.enabled ist unverändert.
• 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 (fuciniCoverage.badge.outputPath, Standard coverage-badge.svg), damit eine README es mit ![coverage](coverage-badge.svg) einbettet, ohne gehosteten Dienst. badge.metric wählt Zeilen, Zweige, MC/DC oder die gewichtete Bewertung; die Farbe folgt den colorScale-Stufen; badge.autoUpdate schreibt es nach jedem Laden neu. Das SVG-Badge, das Export Coverage Report schon anbot, nutzt jetzt denselben Renderer.
• Nicht gemessen versus nicht abgedeckt. Eine Datei, die nie ein Test geladen hat, steht gar nicht in der Tracedatei, deshalb hat die Erweiterung sie schon immer von einer gemessenen Datei mit 0 Treffern getrennt gehalten — und aus den Zahlen herausgehalten, was genau der Grund ist, warum ein Projekt, dessen Module zur Hälfte keine Tests haben, „92%“ liest. Jetzt wird der Unterschied sichtbar: Das Öffnen einer solchen Datei setzt not measured in die Statusleiste, und fuciniCoverage.unmeasured.mode entscheidet, was sonst noch geschieht. list fügt der Coverage-Ansicht eine Gruppe Unmeasured (nicht gemessen) mit jeder Arbeitsbereichsdatei einer vom Lauf gemessenen Art hinzu, die der Lauf nicht enthält, zählt sie im Ladeergebnis, markiert sie mit ? im Explorer, wenn Badges an sind, und lässt threshold.unmeasuredFiles Check Coverage Thresholds ab einer gewählten Zahl fehlschlagen. count geht weiter: Jede solche Datei tritt dem Lauf als 0% bei — eine nicht abgedeckte Zeile je Codezeile —, sodass Statusleiste, Schwellenwerte, Badges, Verlauf, Exporte und die Test-Coverage-Ansicht alle die ehrliche Zahl sehen; die Datei wird überall als nicht gemessen gezeichnet, nie als „passt nicht mehr zu ihrer Abdeckung“. unmeasured.exclude hält Header und dergleichen heraus (standardmäßig **/*.h, **/*.hpp, **/*.hh, **/*.inl, **/*.d.ts). Standardmäßig aus; der Statusleisten-Zustand ist die eine Änderung, die immer an ist.
• Die Abdeckungsansicht zeigt, was das Zusammenführen bewirkt hat. Der eigene Neulauf eines Moduls, der über einen Gesamtprojektlauf geladen wird, ersetzt seit 0.2026.63 dessen Zahlen für die Dateien des Moduls, und jede Zeile nannte den Bericht, aus dem sie stammt — aber eine Zeile, deren Zahlen einen älteren Bericht überstimmt haben, sah genauso aus wie eine, die nur einer von mehreren Berichten gemessen hat, und nichts sagte, wie viel von einem Bericht überstimmt wurde. Jetzt ist das Tracefile-Abzeichen einer solchen Zeile umrandet; jede Tracefile-Zeile über dem Baum zählt, was das Zusammenführen mit ihren Dateien getan hat („42 Dateien · 7 von einem neueren Bericht überstimmt“, „7 Dateien · überstimmt 7 in älteren Berichten“); und ein Klick auf eine Tracefile-Zeile hebt die von ihr gemessenen Dateien im vollständigen Baum hervor und dämpft die übrigen, bis sie erneut angeklickt wird. fuciniCoverage.coverageView.mergedMarks (standardmäßig an) schaltet Umrandung und Hervorhebung ab; die Zähler bleiben.

Behoben

• Ein Business- oder Enterprise-Benutzer wird jetzt nach seinem Einladungscode gefragt, nicht nach dem Firmencode. Seit dem 2. September lehnt der Lizenzserver den gemeinsamen Firmencode für einen Business- oder Enterprise-Seat ab: Ein damit beanspruchter Seat nannte niemanden, deshalb ist jeder Team-Seat jetzt an die Adresse gebunden, an die die Einladung ging, und aktiviert wird er mit dem FCI1…-Einladungscode aus dieser E-Mail. Der Fragebogen beschriftete das Feld aber weiterhin mit „Firmencode“, riet, den Vorgesetzten danach zu fragen, und zeigte einen FCB1…-Platzhalter — er schickte die Leute also los, genau den einen Code einzufügen, der nicht mehr funktioniert, und verlangte dann einen Firmencode, wenn sie das Feld leer ließen. In den Team-Tarifen heißt das Feld jetzt „Einladungscode“, der Hinweis sagt, woher der Code kommt und dass der gemeinsame Firmencode keinen Seat aktiviert, der Platzhalter zeigt die Form FCI1…, und die Validierungsmeldung fragt nach dem Einladungscode. Pro fragt seinen Abonnementcode unter diesem Namen ab. Pro Plus ist unverändert: Es behält den gemeinsamen Code mit Absicht. Alle 17 Anzeigesprachen tragen die neue Formulierung.

Behoben

• ${workspaceFolder} funktioniert jetzt in coverageFile.paths, so wie schon immer in coverageFile.defaultLocation. Die beiden Einstellungen stehen nebeneinander, und nur eine davon dokumentierte die Variable, also schrieben Leute sie in beide — und ein Eintrag, der mit ${ beginnt, ist nicht absolut, sodass er wörtlich unterhalb des Basisordners in das Such-Glob einging, nichts fand, und die Erweiterung meldete, es gebe keine Abdeckung. Ein solcher Eintrag wird jetzt zuerst expandiert, wodurch er zu einem absoluten Pfad wird, und einfach geprüft. In der Einstellung bleibt er so stehen, wie er geschrieben wurde, wird beim Auswählen derselben Datei nicht ein zweites Mal in anderer Form geschrieben und verschwindet von selbst aus der Einstellung, wenn er in der Coverage-Ansicht entladen wird.
• Eine konfigurierte Tracedatei, die nicht existiert, wird jetzt in der Ausgabe gemeldet. Ein Eintrag mit falschem Pfad scheiterte auf die eine Art, die nichts meldete: „keine Abdeckung gefunden“, nicht zu unterscheiden von einem Projekt, das wirklich keine hat. [FUCINI_DISCOVERY] nennt jetzt jeden Eintrag, zu dem keine Datei gefunden wurde, und den Pfad, unter dem gesucht wurde — einmal pro Eintrag statt bei jedem Neuladen; ein Eintrag mit Platzhalter wird nicht gemeldet, da er darauf warten kann, dass ein Build etwas schreibt.

Hinzugefügt

• Die CodeLens je Funktion zeigt jetzt Zweige, MC/DC und eine Gesamtbewertung, nicht nur Zeilen und Treffer — „add: 92 % abgedeckt (12/13 Zeilen, 52 Treffer, Bewertung 88 %, Zweige 3/4 (75 %), MC/DC 2/3 (66 %))“. Jedes davon entfällt bei einer Funktion, zu der die Tracedatei nichts zu melden hat — ein reiner C-Build ohne Zweigdaten oder einer, der nicht mit -fcoverage-mcdc instrumentiert wurde —, statt ein irreführendes 0/0 zu zeigen; die Bewertung erscheint ebenso nur neben mindestens einem der beiden anderen, denn mit Zeilen als einziger Metrik ist sie per Definition dieselbe Zahl, mit der die Lens ohnehin beginnt.
• Der Tooltip des Herkunfts-Badges sagt, wie lange es her ist, dass jede Tracedatei geschrieben wurde, nicht nur ihren Zeitstempel — „Gemessen von module.info (2026-08-15 14:32 · vor 3 Stunden), ersetzt, was lcov.info (2026-08-01 09:10) darüber sagte.“ Die Stufen reichen bis „gerade eben“; nach 30 Tagen wird nur noch das absolute Datum gezeigt.
• Ein Gleichstand bei der mtime von Tracedateien bleibt nicht mehr stumm. Zwei Berichte, die im selben Build-Schritt entstehen, oder ein Dateisystem, dessen mtime-Auflösung gröber als eine Sekunde ist, können für Dateien, die beide messen, denselben Zeitstempel melden — bisher fiel der Gewinner auf die Reihenfolge in coverageFile.paths zurück, ohne dass auf dem Bildschirm irgendetwas das erklärte. Der Ausgabekanal sagt es jetzt: [FUCINI_MERGE_TIE] nennt beide Tracedateien und wie viele Dateien sie gemeinsam haben.
• „Show What Changed Since Last Run“ im …-Menü einer Dateizeile, sobald ein früherer Lauf zum Vergleich vorliegt — dasselbe Delta je Datei, das Compare with Last Run bereits berechnet, gerichtet auf die eine Datei, nach der man gefragt hat, statt auf den ganzen Baum. Eine Datei, in der sich nichts bewegt hat, sagt das schlicht, statt nichts anzubieten.
• Befehl Tune Colour Scale: colorScale.*-Farben und -Schwellenwerte an der laufenden Coverage-Ansicht ausprobieren, bevor man sich festlegt. Jede Änderung wird direkt in die Einstellung geschrieben — die Ansicht zeichnet sich bei jeder Änderung an colorScale/threshold ohnehin neu, das Schreiben des Werts ist also die Vorschau —, und ein abschließendes „Behalten“ oder „Auf die ursprünglichen Werte zurücksetzen“ schließt den Kreis.
• Abdeckungslücken je Datei im Problems-Panel, ein Eintrag pro geladener Quelldatei unterhalb von threshold.statement, hinter dem neuen fuciniCoverage.problems.enabled (standardmäßig aus — der Standard-Schwellenwert für Anweisungen ist 100). Jeder Eintrag fasst zusammen, was nicht abgedeckt ist („62 % Zeilen abgedeckt — 14 nicht abgedeckte Zeilen, 2 nicht abgedeckte Funktionen“), und trägt eine Schnellkorrektur, die die installierte Chat-Erweiterung (Copilot, Claude Code, …) mit einer Aufforderung öffnet, einen Test für die Lücke zu schreiben — eine Diagnose je Zeile würde Problems in einer echten Codebasis überfluten, deshalb bleibt es bei der Dateiebene, der Ebene, auf der ein Leser tatsächlich handeln kann.

Behoben

• Der Grund einer fehlenden, abweichenden oder verifizierten Datei in der Coverage-Ansicht lässt sich jetzt markieren und kopieren. Er stand bisher nur im nativen title-Tooltip der Zeile, der — als Tooltip des Browsers selbst — nicht markierbar ist; wer den genauen Grund in einen Fehlerbericht einfügen wollte, musste ihn von Hand abtippen. Beim Überfahren erscheint derselbe Text jetzt in einem echten, gestalteten Panel, das sich wie jeder andere Seiteninhalt mit der Maus überstreichen lässt. Der Tooltip einer gewöhnlichen Datei (nur ihr Pfad) ist unverändert.
• Eine Funktion, deren Parameterliste sich über mehrere Zeilen erstreckt, wird nicht mehr fälschlich als verschoben gemeldet. detectMismatch ließ zu, dass die aufgezeichnete Zeile einer Deklaration um höchstens zwei Zeilen von der Stelle abweicht, an der ihr Name tatsächlich gefunden wird — genug für die übliche Abweichung zwischen Signaturzeile, Rückgabetypzeile und öffnender Klammer, nicht aber für eine mehrzeilige Parameterliste, die beide beliebig weit auseinanderlegen kann. void LOG_Emit(...) — sieben Parameter, einer je Zeile — aufgezeichnet an ihrer öffnenden Klammer in Zeile 163, wurde als "LOG_Emit" is at line 3 gemeldet: der nächste Textfund, der zufällig der Name der Funktion selbst im Kopfkommentar der Datei war, weit weg von Zeile 163 und von der echten Deklaration in Zeile 156. Die Prüfung akzeptiert jetzt auch einen weiter zurück gefundenen Namen, wenn jede Zeile zwischen ihm und der aufgezeichneten Zeile als eine ununterbrochene Deklaration gelesen wird — keine Leerzeile, keine Zeile, die die vorige Anweisung oder den vorigen Block abschließt —, was eine Parameterliste immer erfüllt und eine tatsächlich verschobene Funktion fast nie. Wo eine Abweichung weiterhin echt ist, ist die gemeldete Zeile jetzt der Fund, der der aufgezeichneten am nächsten liegt, statt immer der erste in der Datei.
• Das Herkunfts-Badge sagt nicht mehr „+N“. Den eigenen Bericht eines Moduls über einen breiteren Lauf zu laden, markierte das Badge der Datei mit dem Namen des Moduls plus der Zahl der anderen Tracedateien, die sie ebenfalls abdeckten — gemeint als „so viele wurden überstimmt“, gelesen als „diese Berichte stimmen überein“, und aus dem Baum war nicht zu erkennen, welche der n tatsächlich gemeint waren. Das Badge nennt jetzt nur noch die Tracedatei, deren Zahlen auf dem Bildschirm stehen; der Tooltip führt weiterhin aus, was überstimmt wurde, und wodurch.
• Das Herkunfts-Badge schiebt den Dateinamen, neben dem es steht, nicht mehr über den Rand des Panels. Die Breite des Badges war fest (flex: none), sodass der Dateiname das gesamte Defizit auffing und zuerst gekürzt wurde, sobald einer Zeile der Platz ausging — obwohl das Badge das weniger wichtige von beiden ist. Das Badge gibt jetzt seine eigene Breite ab, bevor der Dateiname auch nur ein Zeichen verliert; Prozentzahl und Balken, die ohnehin über dem Dateinamen rangieren, sind nicht betroffen.

Geändert

• Der eigene erneute Lauf eines Moduls ersetzt, was ein breiterer Lauf darüber sagte, statt sich dazu zu addieren. Einen projektweiten Bericht und darüber den eigenen Bericht eines einzelnen Moduls zu laden, summierte bisher deren Treffer für jede Datei, die beide gemeinsam hatten — ein erneuter Lauf nur der Tests dieses Moduls blähte Zahlen auf, die ein breiterer, inzwischen veralteter Lauf bereits gemeldet hatte, statt sie zu erneuern. Die Tracedatei mit der neuesten mtime auf der Platte gewinnt jetzt uneingeschränkt für jede Datei, die sie misst: Anweisungen, Zweige, Deklarationen und die Zusammenfassungen je Datei (Zweig-, MC/DC-, Funktions-, Funktionsaufruf-, Objekt- und Mutationszusammenfassungen) stammen alle allein aus diesem Bericht, unabhängig davon, wo die beiden Pfade in coverageFile.paths stehen — ein erneuter Modullauf gewinnt, weil er tatsächlich neuer ist, nicht weil er zufällig zuletzt lädt. Eine Tracedatei, die für eine Datei überhaupt keine Anweisungen meldet — ein TRACE32-Objektcode-Export, ein neben einem echten Bericht geladener Stryker-Mutationsbericht —, trägt weiterhin nur die Zusammenfassung bei, die sie tatsächlich enthält, und lässt die Zeilen- und Zweigdetails eines früheren Berichts unberührt; dieser Fall ist unverändert. Das beseitigt auch einen lange bestehenden Defekt, bei dem eine von zwei Läufen gemessene MC/DC- (oder Funktions-/Funktionsaufruf-/Mutations-)Zusammenfassung je Datei ihren Nenner zusammen mit dem Zähler summiert bekam, was den wahren Prozentsatz zu niedrig auswies. Der Tooltip des Herkunfts-Badges sagt jetzt „ersetzt, was _ darüber sagte“ statt „zusammengezählt“.

Behoben

• Ein langer Dateiname in der Coverage-Ansicht wird jetzt gekürzt, statt überzulaufen. Dem Namens-Span der Zeile fehlte min-width: 0, die eine Deklaration, die overflow/text-overflow: ellipsis eines Flex-Elements überhaupt greifen lässt — ohne sie behielt ein langer Name seine volle Breite, sobald das Panel schmal genug wurde, und lief unter Herkunfts-Badge, Prozentzahl und Balken hindurch, die ihm folgen.

Hinzugefügt

• Die Coverage-Ansicht nach Bewertung sortieren, nicht nur nach Namen. Jede Zeile trägt bereits eine WHM-Bewertung und eine Aufschlüsselung je Metrik; die schlechteste Datei in einem großen Baum zu finden, hieß, eine alphabetische Liste danach abzulesen. Ein Auswahlfeld neben Collapse all / Expand all bietet jetzt Dateiname, Gesamtbewertung, Zeilen, Zweige und MC/DC — jeder Modus außer Dateiname reiht Ordner und Dateien gemeinsam ein, die schlechtesten zuerst nach dem eigenen Prozentsatz dieser Metrik, sodass ein schlecht getesteter Ordner genau wie eine schlecht getestete Datei rangiert, statt von ihr weggruppiert zu werden. Eine Datei ohne Daten für die gewählte Metrik (etwa ein Format, das nie Zweige meldet) sortiert ans Ende, statt als 0 % gelesen zu werden. Die Wahl wird beim Treffen in die neue Einstellung fuciniCoverage.coverageView.sortBy geschrieben, sodass sie ein Neuladen des Fensters überlebt, statt immer wieder bei Dateiname zu beginnen.

Behoben

• Eine mehrzeilige Funktionssignatur wird nicht mehr fälschlich als „verschoben“ markiert. Die fnMap von Istanbul gibt einer Funktion zwei Zeilenangaben — wo ihr Name steht und wo ihr Rumpf beginnt —, und der Parser bevorzugte die Rumpfzeile für die Abweichungsprüfung, die später im Quelltext nach dem Namen sucht. Bei jeder Funktion, deren Parameterliste mehr als zwei Zeilen umfasst (Alltag in einer bei 100 Spalten umbrochenen Codebasis), lag die echte Zeile des Namens zu weit von der aufgezeichneten entfernt, und die Datei wurde in der Coverage-Ansicht mit der falschen Warnung „passt nicht mehr zu ihrer Abdeckung“ abgeblendet. Der Parser bevorzugt jetzt die Zeile des Namens selbst, nach der die Abweichungsprüfung immer schon gesucht hat.

Hinzugefügt

• Jede Zeile sagt, welche Tracedatei sie gemessen hat. Den Bericht eines Moduls über einen projektweiten Lauf zu laden, sind dieselben Dateien, zweimal gemessen, und der Baum sagte nichts darüber, welchen Bericht eine Zeile las. Sind mehrere Tracedateien geladen, trägt jede Dateizeile nun den Namen des Berichts, der sie gemessen hat — des zuletzt geladenen, wenn es mehrere waren — mit +1 je weiterem Bericht und einem Tooltip, der sie nennt. Eine Zusammenführung addiert ihre Treffer, statt einen gewinnen zu lassen, und der Tooltip sagt das. Bei einer einzigen Tracedatei wird nichts gezeichnet, weil es nichts zu unterscheiden gäbe.

Geändert

• Die eigene Seite der Erweiterung nennt jede Einstellung mit ihrem tatsächlichen Standardwert. Zwanzig Einstellungen hatten überhaupt keine Zeile — die Sprache, drei Schwellenwerte, ein Gewicht und die fünfzehn Schalter für Schnellaktionen — und die Telemetriezeile behauptete einen Standardwert von „an“, obwohl sie seit Längerem aus ist. Ein Test vergleicht die Seite nun mit dem Manifest, Standardwerte eingeschlossen.

Behoben

• Die erneute Prüfung von Quellen unter files.watcherExclude, in der vorigen Version eingeführt, folgt nun staleWarning.enabled wie der Rest dieser Prüfung statt einem eigenen Einstellungsnamen.

Geändert

• Der Explorer bleibt unangetastet. Abdeckungs-Badges neben Dateien im Explorer sind standardmäßig aus. Diese Spalte gehört dem, der sie nutzt — VS Code setzt dort gits eigenes M und U hin, und es passt nur ein Badge —, und die Abdeckungsansicht führt dieselben Dateien mit denselben Zahlen an einem Ort, der dafür da ist. explorerBadges.enabled schaltet sie unverändert wieder ein.

Behoben

• Eine Quelle unter files.watcherExclude wird ebenfalls erneut geprüft. Der laufende Abgleich zwischen Datei und Abdeckung wird von Speichervorgängen und einem Dateisystem-Watcher angestoßen, und der schweigt zu allem Ausgeschlossenen — vor allem zu generierten Quellen unter build/, wo eine veraltete Markierung am schwersten auffällt. Diese Dateien werden nun im selben Zwei-Sekunden-Takt wie die Tracedateien abgefragt und nur dann neu gelesen, wenn sie sich wirklich bewegt haben. Ab zweihundert sagt das die Ausgabe, statt den Takt dafür auszugeben.

Hinzugefügt

• Nach dem Test-Runner wird einmal gefragt, nicht bei jedem Lauf. Ein Arbeitsbereich mit mehreren erkannten Runnern — etwa eine jest-Konfiguration und eine go.mod — stellte die Auswahl vor jeden Run Tests with Coverage und verlangte einen Tastendruck für eine längst getroffene Entscheidung. Die Antwort wird nun für den Arbeitsbereich gemerkt, und die Abfrage sagt das. Forget the Test Runner stellt die Frage wieder, und ein gemerkter Runner, den der Arbeitsbereich nicht mehr hat, wird ignoriert statt ausgeführt.

Geändert

• Die eigene Seite der Erweiterung nennt jeden Befehl. Vierzehn der vierunddreißig waren aus ihrer Tabelle herausgefallen — hier und im Handbuch dokumentiert, nur nicht auf der Seite, die man vor der Installation liest. Jetzt stehen alle darin, und ein Test hält das so.

Behoben

• Rückgängig entfernt die Punkte auf bearbeiteten Zeilen wieder. Ein seit dem Lauf bearbeiteter Puffer zeigt graue Punkte auf den neu geschriebenen Zeilen, und die Abdeckung zieht sich dort zurück. Diese Bearbeitungen rückgängig zu machen ließ die Punkte stehen: Jede Änderung zählte, auch eine, die den Text zurückschrieb. Was der Puffer enthielt, bevor jemand tippte, wird nun gemerkt, und sobald er das wieder enthält, verschwinden die Punkte und die Zahlen gelten wieder.
• Die Release-Nummern werden gegeneinander geprüft. Das Manifest, der oberste Changelog-Eintrag und das Release-Tag tragen Version und Build, alle drei von Hand getippt, und sie sind schon auseinandergelaufen. Die Testsuite vergleicht sie nun und prüft, dass die Einträge vom neuesten an laufen, jeder mit einem echten Datum.

Geändert

• Eine entladene Tracedatei bleibt entladen. Eine Datei aus der Liste der Abdeckungsansicht zu nehmen hielt genau so lange wie das Fenster: ohne Konfiguration greift die Suche auf die bekannten Namen zurück und fand am nächsten Morgen wieder lcov.info, und der einzige Weg, etwas anderes zu sagen, war einen Pfad zu konfigurieren, um einen auszuschließen. Diese Entscheidung wird nun für den Arbeitsbereich gemerkt. Sie wird aufgehoben, indem die Datei erneut gewählt oder in coverageFile.paths genannt wird — eine Datei, die die Einstellung nennt, wird nie zurückgehalten, also kann nichts fehlen, ohne dass jemand es gesagt hat.

Behoben

• Schnelleres Neuzeichnen eines bearbeiteten Puffers. Die Liste der neu geschriebenen Zeilen wurde bei jedem Neuzeichnen aus allen aufgezeichneten Bearbeitungen neu berechnet, sodass eine lange, den ganzen Nachmittag bearbeitete Datei Zeilenzahl mal Bearbeitungszahl für eine Antwort zahlte, die sich seit dem letzten Tastendruck nicht geändert hatte. Sie wird nun einmal pro Tastendruck berechnet.

Geändert

• Ein Testlauf merkt sich seine Tracedatei, wie eine Auswahl von Hand. Run Tests with Coverage lud, was der Lauf schrieb, und fragte dann, ob es zu coverageFile.paths hinzugefügt werden soll. Eine von Hand gewählte Datei wird dort seit 0.2026.56 von selbst eingetragen, und ein Testlauf ist dieselbe Handlung auf anderem Weg, also trägt er sie nun genauso ein. Eine Einstellung, coverageFile.rememberPicks, regelt beides; die Zeile der Tracedatei in der Abdeckungsansicht ist der Ort, an dem beide wieder herauskommen.

Behoben

• Die Hintergrund-Timer halten an, wenn die Erweiterung es tut. Der Tracedatei-Watcher wurde mit dem Fenster freigegeben, aber die Zwei-Sekunden-Abfrage dahinter und eine noch ausstehende Quellprüfung sind einfache Timer, die nichts freigibt. Die Erweiterung zu deaktivieren oder ein Fenster mit deaktivierter Erweiterung neu zu laden, ließ sie weiterlaufen und einen Arbeitsbereich lesen, in dem die Erweiterung nichts mehr zu suchen hatte.

Hinzugefügt

• Die Live-Vorschau sagt, was sie zeigt. Die Vorschau des Einstellungsfensters beginnt jetzt mit Lauf: coverage/lcov.info · 12 Dateien und, wenn der aktive Editor eine vom Lauf erfasste Datei zeigt, mit Aktive Datei: src/a.c samt dem eigenen Urteil dieser Datei unter dem des Laufs. Sie folgt dem Editor und jedem Laden, unter dem, was das Formular gerade hält – ungespeicherte Änderungen eingeschlossen. Steht das Fenster vorn, schaltet ein Klick in der Abdeckungsansicht die Vorschau auf diese Datei um, statt sie zu öffnen.
• Der Auswahldialog nennt jedes Format. Zuerst Alle Abdeckungsformate, dann LCOV; JSON (llvm-cov, Istanbul/nyc, coverage.py, SimpleCov, Coveralls, gcov, xccov, Stryker); XML (Cobertura, JaCoCo, Clover, OpenCover, GNATcoverage, Bullseye, SonarQube, VectorCAST, TRACE32, EMMA, UCIS/UCDB, NCover, dotCover, PIT); Go-Abdeckungsprofil; gcov-Listing und Testwell CTC++ – und .lcov, .gcov, .txt und .coveragexml sind nicht mehr ausgegraut.

Geändert

• Die Statusleisten-Hover tragen die Farbskala. Die Metrikbalken in den Lauf- und Datei-Tooltips nehmen die drei Farben von colorScale.*, abgestuft nach der eigenen Schwelle jeder Metrik, wo eine konfiguriert ist, sonst nach den Grenzwerten der Skala; die Urteilsplaketten behalten ihre festen Statusfarben.
• Gezeichnete Flaggen in der Spracheinstellung. Die Flaggen-Emoji aus 0.2026.56 erscheinen unter Windows als zwei nackte Buchstaben. Die Auswahl nennt jede Sprache jetzt bei ihrem eigenen Namen – Nederlands (nl) – mit einer Reihe kleiner gezeichneter Flaggen darunter, die in der Auswahl selektieren.

Hinzugefügt

• Eine Auswahl wird gemerkt. Eine mit Pick Coverage File gewählte Datei lebte nur in dem Fenster, in dem sie gewählt wurde. Sie wandert jetzt von selbst in coverageFile.paths der Arbeitsbereichseinstellungen – relativ zum Basisordner, wenn sie darunter liegt, sonst absolut –, sodass das nächste Fenster sie lädt und der Watcher sie neu lädt. coverageFile.rememberPicks (standardmäßig an) behält das alte Verhalten für alle, die es wollen. Ein absoluter Eintrag in dieser Einstellung benennt jetzt eine Datei, wo immer sie liegt.
• Tracedateien in der Abdeckungsansicht. Über dem Baum eine Zeile je geladener Tracedatei mit ihrer Dateizahl und einer Entladen-Schaltfläche, die sie aus dem Lauf und aus den Einstellungen nimmt; eine Schaltfläche Auswählen… daneben fügt eine hinzu. Das Entladen der letzten Tracedatei leert den Lauf.
• Flaggen in der Spracheinstellung. Die Sprachauswahl des Einstellungsfensters zeigte nackte Codes; jeder Eintrag trägt jetzt eine Flagge und den Namen der Sprache in ihr selbst – 🇳🇱 Nederlands (nl), 🇯🇵 日本語 (ja), 🌐 Automatisch.

Behoben

• Die letzte Zeile einer PHP-Datei zählt nicht mehr als Abdeckung hinter dem Dateiende. Xdebug und PCOV verbuchen das implizite Return am Dateiende auf der Zeile nach dem letzten Zeilenumbruch, sodass php-code-coverage einen Treffer auf „Zeile 252“ einer 251-zeiligen Datei schreibt – und die Abweichungsprüfung das bei jeder PHP-Datei mit abschließendem Umbruch als Widerspruch wertete. Eine Zeile hinter einem abschließenden Umbruch ist jetzt erlaubt; ein Verweis darüber hinaus, oder hinter eine Datei ohne abschließenden Umbruch, bleibt der Widerspruch, der er war.

Hinzugefügt

• Eine Testphasen-Zeile in What Community Includes, in der Community-Edition. Dieser Build hatte nie eine Testphase, also beginnt seine Liste jetzt mit 14-tägige Pro-Testphase starten…, was den Pro-Eintrag öffnet; die Aktivierung des Pro-Builds bietet dann an, den Community-Build aus dem Weg zu räumen. Community bleibt kostenlos, wie auch immer entschieden wird.

Hinzugefügt

• Show Worst-Covered Folders. Die Ordner-Antwort auf Show Worst-Covered Files: jeder Ordner nach der Abdeckung von allem darunter geordnet, der schlechteste zuerst, aus demselben Index, aus dem die Explorer-Badges gezeichnet werden; eine Auswahl zeigt den Ordner im Explorer. Im Statusleistenmenü mit quickActions.worstCoveredFolders.

Hinzugefügt

• Die Schwellenprüfung im Problems-Panel. Mit eingeschaltetem compliance.diagnostics ist jede verfehlte threshold.*-Metrik ein Fehler in Problems, auf der Tracedatei, die sie verfehlt hat, bei jedem Laden und durch Check Coverage Thresholds aktualisiert, gelöscht, sobald die Prüfung besteht. Standardmäßig aus, weil die ausgelieferte Anweisungsschwelle 100 ist.

Geändert

• Die Beschreibung von watch.enabled verspricht keine Rückfrage mehr. Sie sagte noch, die kostenlose Stufe werde vor einem Neuladen gefragt – wahr bis 0.2026.48, seither nicht. In allen 18 Sprachen neu geschrieben.

Hinzugefügt

• Run Tests with Coverage. Erkennt vitest, jest, pytest, go, cargo, dotnet, maven, gradle, phpunit oder ctest am Arbeitsbereichsstamm, führt es mit Abdeckung in einer Terminal-Aufgabe aus, lädt das Geschriebene, ob die Tests bestanden haben oder nicht, und bietet einmal an, diesen Pfad zu coverageFile.paths hinzuzufügen, damit ab dann der Watcher lädt. Mehrere Runner werden zur Auswahl gestellt; keiner schickt Sie zu den Rezepten.

Hinzugefügt

• Abdeckung folgt dem Text in einem bearbeiteten Puffer. Die Bearbeitungen jedes offenen Puffers seit dem Laden des Laufs werden festgehalten, und jede Oberfläche, die Zeilennummern des Laufs liest – die Trefferzahl beim Überfahren, der MC/DC-Balken, das Seit-letztem-Lauf-Dreieck, die CodeLens, Next Uncovered – liest durch sie hindurch: eine Markierung wandert mit ihrer Zeile mit und zieht sich von einer umgeschriebenen zurück, wo ein kleiner grauer Punkt sagt, warum. dirtyMarks.enabled schaltet die Punkte ab.

Hinzugefügt

• Seit dem letzten Lauf, im Gutter. Jede Zeile, die im vorherigen Lauf ausgeführt wurde und in diesem nicht, trägt ein rotes Dreieck im Editor-Gutter, jede Zeile mit dem umgekehrten Verlauf ein grünes, jeweils mit einem Streifen im Übersichtslineal und den Trefferzahlen beim Überfahren. Unveränderte Zeilen zeigen nichts. sinceLastRun.enabled schaltet es ab.

Geändert

• Die Basis für „letzter Lauf“ überlebt einen Neustart. Mit eingeschaltetem history.enabled springt beim ersten Laden eines Fensters der neueste Lauf im Verlauf ein, sodass ein Build, der vor dem Öffnen des Fensters fertig wurde, trotzdem zeigt, was er geändert hat – im Gutter und in Compare with Last Run.

Hinzugefügt

• Das Urteil über eine Datei bleibt nach dem Laden aktuell. Eine Datei wurde einmal gegen ihre Abdeckung geprüft, beim Laden der Tracedatei, und danach nie wieder: einen Nachmittag lang bearbeiten, und die Gutter malten weiter Zahlen über eine Version, die es nicht mehr gab. Jetzt prüft ein Speichern im Editor die Datei sofort erneut, und eine Änderung von außerhalb des Editors — ein git checkout, ein Formatierer, ein Generator — prüft sie kurz darauf von der Festplatte. Eine Datei, die ihrem Lauf widerspricht, bekommt die Markierung; ein Checkout, der die gemessene Version zurückholt, entfernt sie.
• Der genaue Unterschied, beim Überfahren. Wo eine Datei nicht mehr zu ihrer Abdeckung passt, sagen die Abdeckungsansicht und der Explorer-Tooltip genau, was das bewiesen hat: die Zeile, wie sie jetzt lautet, gegenüber dem, was der Bericht festhielt, wenn die Tracedatei den Text bewahrte; die Zeile und eine fehlgeschlagene Prüfsumme, wenn sie einen Digest bewahrte; Abdeckung hinter dem Dateiende; eine Funktion, die nicht mehr dort steht, wo der Bericht sie verortet. Dasselbe Detail geht in den Ausgabekanal, eine Zeile pro Datei, wo Welche anzeigen im Ladeergebnis hinführt.
• Ein Schalter für die Explorer-Badges. explorerBadges.enabled (standardmäßig an) blendet Wert, ✓ und ⚠ neben jeder erfassten Datei im Explorer aus, samt dem Tooltip je Metrik. Gutter, Statusleiste und Abdeckungsansicht bleiben unberührt.

Geändert

• Jede Stufe lädt von selbst neu, wenn sich die Tracedatei ändert. Seit 2026-09-02 blieb die kostenlose Stufe bei der Rückfrage neue Abdeckung erkannt — laden? stehen, während bezahlte Lizenzen still neu luden. Ein Build ist fertig, die Zahlen sind neu, und wer die Überwachung eingeschaltet hat, hat die Frage längst beantwortet — also ist die Rückfrage auf jeder Stufe weg, und der Hinweis, der sie erklärte, ebenso.
• Ladevorgänge, die das Produkt selbst auslöst, zählen nicht mehr gegen das Tageslimit der kostenlosen Stufe. Ein Neuladen durch den Watcher oder die Erkennung beim Start ist kein Laden, um das jemand gebeten hat; sie zu zählen hätte das Kontingent einer Community-Installation an einem Vormittag Testläufe aufgebraucht und dann einen alten Lauf auf dem Bildschirm gelassen, ohne dass etwas darauf hinweist. Das Limit misst jetzt nur den Befehl und die Dateiauswahl.
• Ein geänderter Zeitstempel allein markiert keine Datei mehr. Die Warnung N Datei(en) seit diesem Lauf geändert stammte aus der mtime jeder Quelle, und ein git pull oder ein Formatierer verändert jede mtime, ohne das Gemessene anzutasten. Sie ist weg, samt ihrer Markierung in der Statusleiste. Eine Datei gilt jetzt nur als geändert, wenn ihr Inhalt dem Lauf widerspricht, und Statusleiste, Ladeergebnis und eine neue Ausgabezeile FUCINI_MISMATCH_001 lesen alle daraus. staleWarning.enabled behält seinen Namen und beschreibt jetzt genau die Inhaltsprüfung.
• Die Überwachung eines Ordners unter files.watcherExclude wird in der Ausgabe gesagt. Build-Ausgabe ist das Erste, was man vom Watcher von VS Code ausschließt, wonach nur noch die 2-s-Abfrage einen neuen Lauf bemerkt. Der Ausgabekanal nennt jetzt Ordner und Glob, wenn der Watcher startet.

Hinzugefügt

• Ein Erststart-Hinweis für einen Arbeitsbereich ohne etwas zum Laden. Die Überwachung ist standardmäßig an und der Start-Ladevorgang stumm, also sagte eine frische Installation in einem Projekt ohne Tracedatei gar nichts. Der erste stille Ladevorgang, der leer ausgeht, sagt es jetzt — einmal, für immer — mit den zwei sinnvollen Schritten: eine Coverage-Datei von Hand wählen oder die Rezepte öffnen, wie die eigene Toolchain eine erzeugt. Ein von Hand gestarteter Ladevorgang behält seine eigene Meldung.
• Tasten für Toggle Annotated Source und Load Coverage. Alt+A schaltet den aktiven Tab zwischen Quelltext und annotierter Ansicht um; Alt+Shift+R sucht die Abdeckung neu und lädt sie (Ctrl+Alt+A / Ctrl+Alt+R unter macOS). Umbelegbar wie die beiden aus 0.2026.45.

Geändert

• Pfade, die nichts im Arbeitsbereich treffen, werden auf dem Bildschirm gezählt. Ein Tracedatei-Pfad, der zu keiner Arbeitsbereichsdatei auflöst, lädt und leuchtet nie auf — das häufigste "hat funktioniert, aber nichts ist zu sehen", das es gibt — und bisher war die einzige Spur eine Zeile FUCINI_REMAP_001 im Ausgabekanal, mit der pathRemap-Regel, die es beheben würde, ungelesen. Das Ladeergebnis zählt sie jetzt, mit Welche? für die Namen und die vorgeschlagene Regel und Einstellung pathRemap öffnen für den Ort, an den sie gehört.
• Die Dateiauswahl im Statusleistenmenü nennt die Formate, die sie liest. Ihre Beschreibung zählte noch die fünf Formate der ersten Version auf; jetzt nennt sie fünfundzwanzig, von lcov, Cobertura und JaCoCo bis gcov, llvm-cov, TRACE32 und Mutationsberichten.

Geändert

• Beide Editionen installiert: zwei Schaltflächen statt Anweisungen. Sind Pro und Community beide vorhanden, kann keine von beiden aktivieren — sie definieren dieselben Befehle und Ansichten — und die Meldung dazu endete bisher mit einer Wegbeschreibung zur Erweiterungsansicht. Beide Abhilfen sind je ein Befehl, also sind sie jetzt Schaltflächen: Diese behalten deinstalliert die andere Edition und bietet das Neuladen an; Beide in Erweiterungen anzeigen öffnet die Erweiterungsansicht genau auf diesen beiden. Schlägt die Deinstallation fehl, wird das Neuladen trotzdem angeboten — ein Neuladen entscheidet ohnehin, welche Edition aktiv ist.
• Ein Nutzungslimit wird einmal vollständig gemeldet, danach nur in der Statusleiste. Beim ersten Erreichen eines Community-Limits verdient es die ganze Antwort — die Zahlen, den Tarif, die Telemetrie-Freischaltung, die Liste dessen, was die Stufe enthält. Beim fünften Mal, zehn Minuten später, nicht. Innerhalb einer Sitzung setzen weitere Treffer desselben Limits eine acht Sekunden lange Zeile in die Statusleiste und unterbrechen nichts. Die Eingabe eines Schlüssels beginnt von vorn, denn eine neue Lizenz ist ein neuer Satz Limits.

Hinzugefügt

• Next / Previous Uncovered haben Tasten. Es sind die beiden Befehle, die man beim Lesen einer Datei immer wieder drückt, und bisher hieß jeder Druck: Befehlspalette öffnen und den Namen tippen. Alt+N springt zum nächsten nicht abgedeckten Bereich, Alt+P zum vorherigen (Ctrl+Alt+N / Ctrl+Alt+P unter macOS, wo Option Zeichen eingibt). Beide gelten nur in einem fokussierten Texteditor und lassen sich unter Keyboard Shortcuts wie jede andere Vorgabe umbelegen.

Hinzugefügt

• Was Community enthält, als eine Liste. Die kostenlose Stufe begrenzt acht Aktionen und hält zwölf Funktionen zurück, und jede dieser Entscheidungen wurde an ihrer eigenen Tür durchgesetzt — die Form der Stufe ließ sich also nur lernen, indem man mitten in der Arbeit nacheinander gegen jede Wand lief. Ein neuer Befehl, What Community Includes, zeigt alles auf einmal: jede begrenzte Aktion mit dem bereits verbrauchten Anteil des Tages oder Monats, jede zurückgehaltene Funktion beim Namen, und die zwei Wege, das aufzuheben — ein bezahlter Tarif oder die Telemetrie-Freischaltung.
• Angeboten überall dort, wo die Frage aufkommt. Ein Eintrag im Statusleistenmenü, eine Schaltfläche im Lizenzbanner der Coverage-Ansicht und eine Schaltfläche auf den zwei Meldungen, denen eine Community-Installation an einer Wand begegnet — Nutzungslimit erreicht und diese Aktion ist nicht enthalten. Die Zeilen werden aus derselben Berechtigungsmenge abgeleitet, die die Schranken durchsetzen, also sagt die Liste genau das, was passieren wird.

Geändert

• Der Überwachungsmodus sagt, was er auf der kostenlosen Stufe tun wird. Der Statusleisteneintrag versprach allen, "Abdeckung automatisch neu zu laden", und auf Community ist das ein Versprechen, das der Überwacher nicht hält — er bemerkt es und fragt. Der Eintrag sagt das dort jetzt, und der Befehl heißt Toggle Tracefile Watch, weil "Toggle Watch" nie sagte, was überwacht wird. Das Verhalten selbst ist unverändert.

Geändert

• Eine Tracedatei, die nicht lädt, sagt jetzt warum und was zu versuchen ist. Jeder Fehlschlag erzeugte dieselbe Benachrichtigung — "no coverage could be parsed. See output." — mit dem Grund einen Kanal weiter als Code und Parser-Meldung. Die Benachrichtigung beginnt jetzt mit der Datei und sortiert die Ablehnung nach dem, was sie war: kein Format, das diese Erweiterung liest, nicht wohlgeformt (meist ein Build, der noch schrieb), wohlgeformt, aber ohne Messung (der Lauf führte keinen instrumentierten Code aus) oder konnte nicht gelesen werden. Die Worte des Parsers selbst gehen mit, mehrere Dateien werden gezählt, und der Ausgabekanal wird hinter einer Schaltfläche Ausgabe anzeigen angeboten statt erzwungen geöffnet.
• Dateien, die eine Tracedatei nennt, in denen aber nichts zu messen ist, werden jetzt auf dem Bildschirm gezählt. Ein reiner Deklarations-Header blieb schon immer aus der Coverage-Ansicht heraus, statt mit 100% aus 0 von 0 bewertet zu werden — und sein Name landete im Ausgabekanal, und nirgends sonst. Das Ladeergebnis sagt jetzt N Datei(en) ohne instrumentierbaren Code werden nicht angezeigt, mit einer Schaltfläche Welche?, die den Kanal mit den Namen öffnet.

Hinzugefügt

• NCover und JetBrains dotCover. Coverlets Cobertura und OpenCover wurden hier bereits gelesen, was die meiste neue .NET-Arbeit abdeckt und nichts von der älteren Art. Ein Build, der noch NCovers Coverage.xml schreibt, oder ein Team, das mit dotCover misst, hatte Coverage auf der Platte, die diese Erweiterung nicht öffnen konnte. Keines der Formate braucht einen Konverter: beide tragen bereits Dateinamen und Zeilennummern.
• Ein ausgeschlossener NCover-Punkt wird verworfen, nicht als nicht getroffen gewertet. excluded="true" markiert Code, der bewusst aus der Messung genommen wurde — ein Member mit [ExcludeFromCodeCoverage], oder ein NCoverExplorer-Filter. Ihn als nicht abgedeckt zu zählen würde einen Ausschluss die Zahl senken lassen, die er eigentlich korrigieren sollte.
• dotCover braucht /ReportType=DetailedXML. Sein anderer XML-Bericht ist ein Rollup ohne jegliche Zeilennummern; dieser Bericht wird erkannt und mit dem Hinweis auf das lösende Flag abgewiesen, statt als unbekanntes Format zu scheitern. dotCover erfasst pro Anweisung nur Ja oder Nein, nie eine Besuchszahl, sodass eine abgedeckte Anweisung einen einzigen Treffer ergibt.

Hinzugefügt

• Mutationstests. Coverage sagt, dass eine Zeile lief; ein Mutations-Score sagt, dass etwas fehlschlug, als diese Zeile geändert wurde. Eine Suite kann jede Zeile einer Datei ausführen und keinen der eingeschleusten Fehler erkennen, und keine Coverage-Zahl sagt das. PIT deckt Java, Kotlin und Scala ab; Stryker deckt JavaScript, TypeScript, C# und Scala ab.
• Er wird nie mit Coverage gemittelt. „Lief diese Zeile“ mit „hat irgendetwas es bemerkt, als ich sie änderte“ zu vermischen, beantwortet keine der beiden Fragen; deshalb erhält er kein Gewicht im zusammengesetzten Score und wird separat über fuciniCoverage.threshold.mutation geprüft — standardmäßig 0, weil ein Mutations-Score ein Ziel ist, das man anhebt, keine Latte, die am ersten Tag schon gerissen werden muss.
• Ein Mutant, der nie einen fairen Lauf bekam, zählt in keiner der beiden Hälften. PITs NON_VIABLE und Strykers CompileError und Ignored sind Mutationen, die das Werkzeug nicht erzeugen konnte; sie als unentdeckt zu werten würde eine Suite für einen Fehler bestrafen, der ihr nie angeboten wurde.

Hinzugefügt

• Das annotierte .gcov-Listing. gcov --json-format kam mit GCC 9, und Embedded-Cross-Compiler sind oft weit älter; bisher lautete die Antwort, erst lcov oder gcovr zu installieren. Der Ausführungszähler hat fünf Schreibweisen, und nur zwei davon sind Zahlen, und branch/call/function-Annotationen gehören zur Nachbarzeile statt zur eigenen — all das wird jetzt korrekt gelesen.
• Call-Annotationen werden zu Call-Site-Coverage. call N returned X% ist genau die in 0.2025.38 hinzugefügte Funktionsaufruf-Metrik, die dieses Format schon lange trug, bevor es hier einen Platz dafür gab.

Hinzugefügt

• Objektcode-Coverage — wie viel des gebauten Binärprogramms tatsächlich lief. Die einzige Metrik hier, die überhaupt nicht am Quelltext gemessen wird: Sie stammt von einem Debugger, der den Instruktionsstrom auf dem echten Zielsystem beobachtet, ohne jeden Sondeneffekt auf das Timing. Sie ist auch die ehrliche Antwort auf die Frage "deckt das Assembler ab?" — handgeschriebener Assembler wird nie instrumentiert, und keine andere Metrik hier kann ihn erreichen.
• Sie ist eine Anforderung, kein weiteres Gewicht. Objektcode-Coverage subsumiert Anweisungsüberdeckung — 100% hier bedeutet 100% dort, aber nicht umgekehrt — daher erhält sie kein Gewicht im zusammengesetzten Score und wird stattdessen über einen Schwellenwert geprüft, genau wie DO-178C Stufe A es zusätzlich zu MC/DC verlangt.
• 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 "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 — wird als Widerspruch gemeldet, nicht als niedriger Wert.

Hinzugefügt

• Funktionsaufruf-Coverage — wurde jede Aufrufstelle ausgeführt. Eine andere Frage als Funktionsüberdeckung: Eine Funktion, die einmal von einer ihrer drei Aufrufstellen aus aufgerufen wird, ist unter Funktionen vollständig und hier zu einem Drittel vollständig. VectorCAST, TRACE32 und Cantata meldeten dies alle, während dieses Modell keinen Platz für die Zahl hatte.
• Das vervollständigt VectorCAST und TRACE32. Frühere Versionen weigerten sich bewusst, diese Daten in die Zweigüberdeckung einzufalten, weil das Aufblähen eines Zweigprozentsatzes eine Zahl aufbläht, die in einem Audit landet. Beide Formate laden jetzt, was sie schon immer sendeten.

Geändert

• Das Compliance-Gate und der gewichtete Score kennen jetzt sieben Metriken, nicht sechs — zwei neue Einstellungen, fuciniCoverage.whmWeights.functionCalls und fuciniCoverage.threshold.functionCalls, mit Beschreibungen in allen 17 Sprachen.

Geändert

• Funktionsüberdeckung zählt jetzt auch, wenn das Werkzeug nicht sagt, wo die Funktionen sind. TRACE32s func-Export, VectorCASTs selbstschließende <method>-Elemente und EMMAs method, %-Rollup nennen alle drei eine Funktionsanzahl, ohne irgendwo einen CodeLens platzieren zu können — alle drei wurden beim Einlesen verworfen. Deklarationen bleiben die bevorzugte Quelle, wo sie existieren; die Zahl wird jetzt als Rückfalloption verwendet, wo es keine gibt.

Hinzugefügt

• UCIS- und UCDB-XML — VHDL und Verilog, direkt aus dem Simulator. Zwei Dokumente tragen diesen Namen, und ein Projekt hat, was sein Simulator auch geschrieben hat, also werden beide gelesen: Accelleras Standard-Austauschform <UCIS>, und Aldecs eigenes ux:ucdb, was acdb2xml tatsächlich aus Active-HDL und Riviera-PRO erzeugt. Anweisungs- und Zweigüberdeckung kommen mit; Toggle-, FSM-, Assertion- und funktionale Coverage werden nicht gelesen, und ein Dokument, das nur diese enthält, sagt das, statt leer zu laden.
• Open-Source-VHDL brauchte hier bereits nichts: GHDLs GCC-Backend instrumentiert mit -Wc,-ftest-coverage -Wc,-fprofile-arcs, und das Ergebnis läuft über gcov, gcovr oder lcov. Diese Version ist für die kommerziellen Simulatoren.

Hinzugefügt

• EMMA XML. Delphi hatte hier überhaupt keinen Zugang — kein lcov, kein Cobertura — und DelphiCodeCoverage schreibt genau dieses Schema mit -xml. Es ist auch, was ein gutes Stück älteres Java-Tooling noch immer ausgibt, sodass ein Parser eine Sprache erschließt und zugleich ein Altsystem abräumt.
• Fügen Sie -xmllines hinzu, und der Bericht erhält echte zeilenweise Trefferzahlen, sodass Gutter funktionieren; ohne gibt es nur einen Rollup-Prozentsatz, der eine Dateizusammenfassung und keine Gutter erhält, statt eine Vermutung. Ein gepunkteter Paketname wird nur zu einem Verzeichnis, wenn die Datei eine Quelle der Java-Familie ist; in einem Delphi-Bericht ist dasselbe Feld ein Unit-Name, und ihm ein Präfix voranzustellen würde einen Ordner erfinden, den niemand auf der Platte hat.

Hinzugefügt

• TRACE32-Coverage-Exporte. COVerage.EXPORT.ListModule schreibt, was ein Debugger aus On-Target-Trace gemessen hat — kein instrumentierter Quelltext, sondern der Instruktionsstrom, den der Prozessor tatsächlich ausführte, auf dem echten Zielsystem, ohne jeden Sondeneffekt auf das Timing. Ein Export trägt jeweils eine Metrik: stmt wird zur Zeilenüberdeckung; dec/cond werden zur Zweigüberdeckung; mcdc wird zu MC/DC. Laden Sie zwei Exporte desselben Laufs, und sie werden nach Modulname zusammengeführt.
• Exporte mit func-, call- oder object-Coverage wurden namentlich abgelehnt statt leer geladen, mit Angabe, welche Metrik die Datei enthält — alle drei haben jetzt ein Zuhause, in 0.2025.37, 0.2025.38 bzw. 0.2025.39.

Hinzugefügt

• Testwell-CTC++-Ausführungsprofil-Listings. ctcpost wandelt MON.sym und MON.dat in ein Festbreiten-Textlisting um — das Werkzeug, das europäischen Embedded- und sicherheitskritischen Teams gegenüber Bullseye steht und das Mehrfachbedingungsüberdeckung misst. Es wird spaltenweise gelesen statt durch Aufsplitten an Leerraum, weil eine Beschreibung selbst mit einer Ziffer beginnen kann.
• Mehrfachbedingung ist kein MC/DC und wird nicht als MC/DC gemeldet. CTC++ zählt Kombinationen von Bedingungen; MC/DC fragt, ob gezeigt wurde, dass jede Bedingung das Ergebnis unabhängig beeinflusst. Diese Zahlen hinter das MC/DC-Gate zu stellen, würde einem Prüfer eine Zahl unter einem Namen geben, den sie nicht bedeutet, also sind sie hier Zweigüberdeckung, was sie auch sind.

Hinzugefügt

• VectorCAST XML. VectorCAST schreibt einen Cobertura-Bericht bis hin zum Doctype und fügt dann Attribute für das hinzu, was gewöhnliches Cobertura nicht sagen kann. Das bedeutete, diese Dateien luden hier bereits und wirkten vollständig — wobei mcdcpair-coverage beim Einlesen still verworfen wurde, ausgerechnet bei dem Publikum, das ein Werkzeug speziell dafür gekauft hatte, es zu erzeugen. Diese Paarzählungen überleben jetzt. Sie speisen das MC/DC-Gate, den Prozentsatz und den zusammengesetzten Score.
• Funktionsaufruf-Coverage wird bewusst nicht angenähert. Sie in Zweigüberdeckung einzufalten würde eine Zahl aufblähen, die in einem Audit landet; sie wartet, bis das Modell einen Namen dafür hat, was in 0.2025.38 geschieht.

Geändert

• Der Cobertura-Reader trägt jetzt einen Dialekt: <coverage line-rate=…> ist eine Familie, kein einzelnes Format, und welcher Dialekt gelesen wird, reist mit dem Parsevorgang mit, statt pro Element geraten zu werden.

Hinzugefügt

• GNATcoverage XML — endlich Ada. DO-178C-Avionik- und EN-50128-Bahnteams sind genau das Publikum, für das der sicherheitsgewichtete Score und die MC/DC-Unterstützung dieses Produkts gebaut wurden, und bis jetzt konnten sie hier gar nichts laden, sofern ihr gnatcov nicht neu genug war, um auch Cobertura auszugeben — was alles unterhalb der Zeile verwirft. gnatcov coverage --annotate=xml schreibt ein Verzeichnis statt einer Datei: Laden Sie die *.xml-Dateien je Quelldatei — beim Öffnen von index.xml erfahren Sie, wo die Abdeckung tatsächlich liegt, statt einen unklaren Fehler zu sehen. Eine teilweise abgedeckte Zeile bleibt eine abgedeckte Zeile mit einer nicht abgedeckten Entscheidung: Das Defizit erscheint in der Zweig- und MC/DC-Abdeckung, wo es hingehört. Ausnahmebereiche werden zu ausgeschlossenen Zeilen, eine unbestimmte Verpflichtung zählt als nicht abgedeckt statt als abgedeckt, und mit --level=stmt+mcdc wird MC/DC je Bedingung gezählt und steuert Schwellenwert und Gesamtscore.
• BullseyeCoverage und Visual Studio .coveragexml. Bullseye ist das kommerzielle C/C++-Werkzeug, das Embedded- und sicherheitskritische Teams tatsächlich besitzen; führen Sie dessen covxml aus und laden Sie das Ergebnis. Seine Leitkennzahl ist Bedingungs-/Entscheidungsabdeckung statt Zeilenabdeckung, und beide bleiben hier getrennt — außerdem wird eine Sonde mit nur einem Ausgang aus eins statt aus zwei bewertet, damit ein vollständig getestetes switch nicht als halb abgedeckt erscheint. Visual Studios .coveragexml vervollständigt .NET für Teams mit MSTest und vstest statt Coverlet: Wandeln Sie die binäre .coverage-Datei zuerst mit dotnet-coverage convert um. Teilweise abgedeckte Zeilen überstehen den Weg in beiden Fällen.
• SonarQube Generic Coverage — und eine klare Antwort zu Xcode. Vier Attribute an zwei Elementen, und es zählt, weil fast jedes Werkzeug, das keines der anderen Formate ausgeben kann, dieses ausgeben kann — ein Projekt, dessen Coverage-Werkzeug diese Erweiterung nie gehört hat, hat damit einen Weg herein. Es ist außerdem das, was xcresultparser schreibt, und so kommen Swift- und Objective-C-Projekte hier an: .xcresult selbst hat keinen Parser, und die Dokumentation sagt jetzt warum, statt Sie raten zu lassen — xccov meldet Prozentwerte, keine Daten je Zeile, und das Archiv mit Zeilendaten lässt sich nur Datei für Datei lesen, in einem Dokument, das die beschriebene Datei nie benennt.
• Gzip-komprimierte Tracefiles laden direkt. gcov --json-format schreibt standardmäßig .gcov.json.gz — das angekündigte Format war also eines, das die meisten gar nicht laden konnten. Erkannt wird an den Magic Bytes der Datei statt am Namen: Ein komprimierter Bericht, der sein .gz verloren hat, funktioniert weiterhin — und jedes unterstützte Format darf jetzt gzip-komprimiert ankommen, nicht nur das von gcov.
• Swift und Objective-C, aus Xcodes eigenem Bericht. xcrun xccov view --report --json ist das eine Coverage-Dokument, das ein iOS- oder macOS-Build ohne zusätzliche Werkzeuge erzeugt. Sie erhalten Dateiprozentwerte, Ausführungszahlen je Funktion und CodeLens. Es enthält keine zeilengenauen Daten, und Studio erfindet keine, daher bleiben die Gutter-Markierungen bei diesem Format leer — eine erfundene Markierung ist von einer gemessenen nicht zu unterscheiden. Für zeilengenaue Swift-Coverage verwenden Sie llvm-cov export -format=lcov oder slather; beides funktionierte bereits.
• Coveralls JSON — von Reportern für Elixir, Ruby, Python, Rust, Go und JavaScript gleichermaßen geschrieben. Zeilengenau, also funktionieren die Gutter-Markierungen.
• Aktive Tage, blockierende Gates und die Lizenz, zu der eine Zusammenfassung gehört — drei Ergänzungen der monatlichen Nutzungsübersicht, für Installationen mit aktivierter Telemetrie.

Entfernt

• Der Computername wird nicht mehr gesendet. hostname war von Anfang an Teil der Telemetrie-Basis — außerhalb jeder Gate-Prüfung, gesendet von allen mit aktivierter Telemetrie. Ein Computername ist sehr oft der Name einer Person, eine Schreibtischnummer oder das Projekt eines Kunden, und er beantwortete keine Frage zur Nutzung, die das Betriebssystem nicht besser beantwortet hätte. Eine Installation wird jetzt allein durch ihre zufällige Install-ID identifiziert. Damit verlässt nichts Ihren Rechner, das Sie oder ihn benennt: weder der Computername noch der Betriebssystem-Benutzername, das Home-Verzeichnis, die Netzwerkschnittstellen, Ihre Dateipfade, der Ordnername Ihres Projekts oder ein angemeldetes Konto. Was bleibt, sind Betriebssystem, Release und Architektur — welche Art von Rechner, nicht welcher.
• Telemetriedaten werden jetzt spätestens nach 90 Tagen gelöscht, während die Richtlinie zuvor nur sagte, sie würden „aufbewahrt, solange sie nützlich sind“ — das ist überhaupt keine Frist.

Geändert

• Eine kostenpflichtige Lizenz lädt Coverage jetzt von selbst neu. Ein Tracefile zu überwachen hieß bisher, nach jedem Build gefragt zu werden: „Neue Coverage erkannt, laden?“ — auf jeder Stufe, eine Frage mit genau einer sinnvollen Antwort, mehrmals pro Stunde gestellt. Diese Abfrage ist jetzt das Verhalten der kostenlosen Community-Stufe; eine kostenpflichtige Lizenz lädt einfach. Community behält den Watcher, die Erkennung und die Abfrage, die sie immer hatte.
• Eine nicht passende Datei wird benannt, samt der Prüfung, die es belegt hat — mit kostenpflichtiger Lizenz. Die Erkennung ist nicht eingeschränkt und wird es nicht sein: jemandem zu sagen, dass seine Coverage seine Datei nicht mehr beschreibt, ist nichts, was man ihm verkauft. Community erhält den Befund weiterhin, und die Zeile wird weiterhin abgeblendet. Eine kostenpflichtige Lizenz ergänzt den Hinweis — die Markierung, das Explorer-Kennzeichen und die Zeile, Funktion oder Prüfsumme dahinter.
• Telemetrie sendet weniger und sagt, zu wem sie gehört. Die monatliche Zusammenfassung enthält keine Dateipfade, keinen Ordnernamen Ihres Projekts und keine Kontobezeichnung mehr. Der Tausch „kostenlose Funktionen gegen Telemetrie“ fragt jetzt nach einer E-Mail-Adresse, damit wir demjenigen, der zugestimmt hat, sagen können, was seine Installation sendet, und es auf Wunsch löschen können.
• Drei Einstellungsbeschreibungen korrigiert. watch.enabled, staleWarning.enabled und telemetry.enabled wichen jeweils davon ab, was der Code tut — telemetry.enabled am deutlichsten: Es beschrieb, dass erheblich mehr gesendet wird, als tatsächlich gesendet wird.

Behoben

• Die Dateiauswahl versteckt keine Formate mehr, die sie liest. Pick Coverage File filterte auf info, json und xml, sodass Gos coverage.out und gcovs .gcov.json.gz — beides Formate, die diese Erweiterung liest — ausgerechnet in dem Dialog ausgegraut waren, der Sie um die Auswahl bittet.
• Eine einfache Community-Installation sendet keine Seite ihres Quelltextes mehr. Die Prüfung, die die Quelltextstichprobe absichert, behandelte jede Community-Installation so, als hätte sie den Telemetrie-Tausch angenommen — nicht nur die, die es tatsächlich getan hatten.
• Eine Warnung pro Ladevorgang statt zwei — eine Datei, die nicht mehr zu ihrer Coverage passt, wurde fast immer auch seit dem Lauf bearbeitet, und beides wurde getrennt gemeldet.
• Eine Deinstallation meldet nicht mehr den Betriebssystem-Benutzernamen und das Home-Verzeichnis von jemandem, dessen Lizenz das verbietet.

Hinzugefügt

• Go-Abdeckungsprofile. go test -coverprofile ist die einzige Abdeckungsausgabe, die die Standard-Toolchain von Go erzeugt — es gibt kein lcov als Rückfallebene wie bei Rust, Dart und Elixir —, also hatte ein Go-Projekt nichts, was diese Erweiterung hätte lesen können. Ein Profil erfasst Blöcke statt Zeilen, und jede Zeile, die ein Block überspannt, erhält dessen Zähler, schließende Klammer eingeschlossen, genau so, wie go tool cover -html sie hervorhebt. coverage.out gehört jetzt zu den Suchnamen, sodass ein Go-Projekt ohne jede Konfiguration sein Profil findet, wie ein C-Projekt lcov.info findet.
• Clover XML und OpenCover XML. Clover ist das, was PHP-Projekte tatsächlich haben: php-code-coverage kann Cobertura ausgeben, aber Clover ist der Standard und das, was nahezu jede phpunit.xml konfiguriert — PHP-Abdeckung war hier also unlesbar, während ein Cobertura-Parser auf eine Ausgabe wartete, die fast niemand erzeugt. Istanbuls clover-Reporter schreibt dasselbe Dokument, ein so konfiguriertes Jest-Projekt ist damit ebenfalls abgedeckt. OpenCover ist das .NET-Gegenstück: C# und VB.NET kamen bereits als Cobertura an, das eine Entscheidung zur Zeichenfolge condition-coverage="50% (1/2)" plättet — welcher Zweig lief, war also verschwunden, bevor ein Parser ihn sah. OpenCover behält einen Zähler je Zweig: der Unterschied zwischen „die Hälfte dieser Verzweigung ist abgedeckt“ und dem Wissen, welche Hälfte.
• coverage.py-JSON und gcov/gcovr-JSON. Die Cobertura- und lcov-Exporte von coverage.py müssen eine # pragma: no cover-Zeile entweder abgedeckt oder fehlend nennen, weil sie kein Wort für „bewusst ausgeschlossen“ haben — diese Erweiterung hat eines, dieselbe Markierung, die ihre LCOV_EXCL-Marker setzen. Die Pragmas eines Python-Projekts bedeuten hier also jetzt dasselbe wie im eigenen Bericht von coverage.py. GCC-Abdeckung wiederum kam nur nach einem Umweg über lcov oder gcovr -x an: ein zweites Werkzeug, um Daten umzuwandeln, die GCC bereits erzeugt hatte. gcov --json-format --stdout und gcovr --json geben nahezu identische Dokumente aus, und ein Parser liest jetzt beide.

Behoben

• Kommentare werden in der Sprache gelesen, in der die Datei geschrieben ist. Der Scanner für Nicht-Code-Zeilen war für C geschrieben und wurde auf jede Datei angewendet, was richtig war, solange jedes Format, das diese Erweiterung las, eine Sprache der C-Familie beschrieb. Das ist es nicht mehr: Ein C-Scanner, der auf # don't trifft, sieht das Apostroph eine Zeichenkette öffnen, sieht sie nie schließen und zählt die Kommentarzeile als Code — eine Zahl, die still ein wenig falsch ist, ohne dass irgendetwas darauf hinweist. Jetzt gilt # für Python, Ruby, Shell, Perl, R, Elixir und Julia; alle drei Formen für PHP, das alle drei akzeptiert; und // mit /* */ für alles andere, was die Vorgabe für eine unbekannte Dateiendung bleibt — #define ist Code, und ihn auszuschließen wäre in die andere Richtung falsch.

Hinzugefügt

• Jede fuciniCoverage.*-Einstellung hat nun einen Platz in diesem Panel, nicht nur die dreizehn Compliance-Einstellungen. Alle fünfundfünfzig sind in dieselben Abschnitte und in derselben Reihenfolge gruppiert wie in der veröffentlichten Einstellungsreferenz, sodass die Seite, von der aus Sie konfigurieren, und die Seite, die Sie lesen, sich darüber einig sind, wo eine Einstellung hingehört. Ein Suchfeld filtert nach Name, Schlüssel oder Beschreibung; eine Sprungliste wechselt zwischen den Abschnitten. Das Formular wird zur Laufzeit aus dem eigenen mitgelieferten Manifest der Erweiterung abgeleitet — Typen, Standardwerte, Grenzen, Aufzählungen und jedes Wort Text — sodass nichts über eine Einstellung zweimal festgehalten ist und das Panel nicht von der Erweiterung abweichen kann, die es bearbeitet.
• Die Beschreibungen folgen der Sprache, die Sie festgelegt haben. VS Code löst die Lokalisierung eines Manifests beim Laden der Erweiterung aus der Anzeigesprache des Editors auf und bietet keine Möglichkeit, das pro Erweiterung zu überschreiben — fuciniCoverage.language auf Deutsch zu stellen, übersetzte in einem englischen Editor also alles außer den Einstellungen. Weil das Panel diese Dateien selbst liest und auflöst, ist es die einzige Stelle, die diese Festlegung berücksichtigen kann.
• Die Bedienelemente, die ein JSON-Schema nicht anfordern kann. Nichts in einem Einstellungsschema kennzeichnet eine Zeichenfolge als Pfad, also kann die native Oberfläche dafür keine Auswahl anbieten; die drei Einstellungen, die ein Verzeichnis enthalten, erhalten jetzt eine Schaltfläche Durchsuchen…. coverageFile.paths und pathRemap bekommen echte Listeneditoren statt eines rohen JSON-Felds, und jede colorScale-Farbe eine Farbfläche neben ihrem Hex-Wert.

Geändert

• Speichern schreibt, was Sie geändert haben — und sonst nichts. Bei dreizehn Einstellungen fiel es kaum ins Gewicht, dass Speichern alle dreizehn schrieb; bei fünfundfünfzig hieße das, dass eine einzige Änderung den gesamten Namensraum in eine settings.json stempelt, in der zwei Zeilen standen. Geschrieben werden nur Einstellungen, deren Wert sich tatsächlich geändert hat, und ein Wert, der dem Standard entspricht, entfernt die Überschreibung, statt zu wiederholen, was die Erweiterung ohnehin ausliefert.
• Ihr Lizenzschlüssel geht immer in Ihre Benutzereinstellungen, und die Zeile sagt das auch. license.key ist als anwendungsweit deklariert, das heißt, VS Code liest ihn ausschließlich von dort — ihn in einen Arbeitsbereich zu schreiben ist ein Speichern, das zu funktionieren scheint und nichts ändert. Zurücksetzen löscht nun alle fünfundfünfzig Schlüssel im gewählten Bereich statt dreizehn und fragt deshalb vorher nach. Und eine Änderung außerhalb des Panels kostet Sie nicht mehr Ihre Position: Die Seite vergleicht, bevor sie neu zeichnet, sodass Speichern fünfundfünfzig Zeilen nicht mehr an den Anfang zurückscrollt.

Hinzugefügt

• Der Compliance-Modus, die sieben Schwellenwert-Kriterien und die sechs Gewichte des Gesamtscores haben jetzt einen gemeinsamen Editor. In der Einstellungsoberfläche sind sie dreizehn unabhängige Zeilen, in der Praxis eine einzige Entscheidung: Ein Schwellenwert bleibt wirkungslos, solange ihn der geltende Modus nicht heranzieht, und ein Gewicht bleibt wirkungslos, solange nicht das gewichtete Kriterium entscheidet. Fucini Coverage: Configure Coverage Compliance & Thresholds... — über die Zahnrad-Schaltfläche in der Titelleiste der Coverage-Ansicht — fasst die drei zusammen, erklärt jeden Modus dort, wo der Modus gewählt wird, und benennt die Kombinationen, mit denen ein Kriterium nichts mehr prüft — ein strikter Modus ohne gesetzten Schwellenwert je Metrik, ein gewichteter Modus mit Schwellenwert 0, Gewichte, die alle 0 sind — als Warnungen, während Sie davor sitzen.
• Es zeigt das Urteil vorab und schreibt über VS Code. Das COMPLIANT / NON-COMPLIANT, das das ungespeicherte Formular gegen den geladenen Lauf ergäbe, berechnet die Compliance-Engine der Erweiterung selbst und nicht eine zweite Kopie der Regeln — eine Vorschau, die dem Kriterium widersprechen kann, ist schlechter als gar keine. Änderungen laufen über die reguläre Konfigurations-API in settings.json — Benutzer oder Arbeitsbereich, Ihre Wahl —, sodass VS Code die Datei formatiert und ihre Kommentare behält; eine Änderung von Hand oder in einem anderen Fenster fließt zurück in das offene Formular, ob ein Lauf geladen ist oder nicht. Eine Lizenz ist nicht nötig: Community erhält denselben Editor wie Pro.

Behoben

• Die Schaltfläche der Update-Benachrichtigung lautete Download && Install. Das doppelte kaufmännische Und ist die Mnemonic-Maskierung und in package.json-Titeln sowie in modalen Dialogen richtig — die Aktionsschaltflächen einer Benachrichtigung übernehmen ihre Beschriftung jedoch als reinen Text, sodass beide Zeichen genau so ausgegeben wurden, wie sie dastanden, in allen 17 Sprachen, für jeden, dem ein Update angeboten wurde.

Geändert

• Telemetrie ist standardmäßig aus. Sie wurde standardmäßig eingeschaltet ausgeliefert, mit der Begründung, die Evaluierungsphase brauche die Daten. Diese Begründung galt nicht mehr, sobald die Community-Stufe das Einschalten der Telemetrie zu dem machte, was jede Pro-Funktion kostenlos freischaltet: Ein Tausch bedeutet nur etwas, wenn die Person ihn selbst eingeht, und ein Tausch, für den sich niemand entschieden hat, ist keiner. Es wird nichts gesendet, bis Sie sie einschalten, und Community arbeitet ohnehin mit seinem Standardumfang weiter.
• Die Telemetrie-Einstellung sagt, wozu sie da ist, und verlinkt den Rest. Ihre Beschreibung zählte früher jedes Feld auf, das ein Ping mitträgt — also zwei Kopien dieser Liste, eine in der Einstellung, eine in der Datenschutzerklärung, die auf ewig identisch bleiben mussten und es nicht waren. Jetzt sagt sie, was das Einschalten bringt, und verlinkt für die Feldliste auf die Datenschutzerklärung: eine Liste, die stimmen muss, statt zweier.
• Dieses Release zu installieren öffnet Ihr Evaluierungsfenster wieder, einmalig. Wer seine Testphase bereits aufgebraucht hatte, bekommt frische 14 Tage, weil dieses Release die Bedingungen ändert, unter denen evaluiert wurde: Eine Testphase mit standardmäßig eingeschalteter Telemetrie war keine Testphase des Produkts, das jetzt angeboten wird. Das ist bewusst an ein einmaliges Token gebunden und nicht an die Version — bei jedem Release zurückzusetzen hieße, dass die Testphase für niemanden endet, der auf dem Laufenden bleibt, und das ist keine Testphase, sondern eine unbepreiste Lizenz mit Zusatzschritten. Das Token wird bei der ersten Aktivierung verbraucht, danach gelten wieder die gewöhnlichen Regeln. Eine bezahlte Lizenz bleibt unberührt, da die Schlüsselprüfung zurückkehrt, bevor die Testphase überhaupt herangezogen wird, und Community ist nicht betroffen, weil diese Edition keine Testphase hat, die sich wieder öffnen ließe.
• Ein Lizenzschlüssel kostet keinen Fragebogen mehr. Die Aktivierungshinweise, die Lizenzschlüssel-Einstellung und der Dialog am Ende der Testphase stellten einen Schlüssel alle als etwas dar, das im Austausch für beantwortete Fragen ausgestellt wird. Das ist er nicht: Der Schlüssel wird auf Anfrage automatisch ausgestellt, und der Feedback-Fragebogen ist freiwillig und davon vollständig getrennt.

Behoben

• Drei Stellen versprachen noch immer eine Testphase "bis 2026-12-31". Ein solches Datum hat es im Produkt nie gegeben — die Testphase dauert 14 Tage, je Installation ab der ersten Nutzung gezählt. Zwei frühere Releases haben diese Behauptung in den Einstellungsbeschreibungen und in der README gefunden; sie überlebte im Evaluierungshinweis dieser Seite, im Benutzerhandbuch und in der README des Lizenz-Werkzeugs. Das Benutzerhandbuch war das schlimmste der drei: Dort stand, das Fenster gelte "für jede Installation, weltweit, gleichzeitig (kein Countdown pro Installation)", also genau umgekehrt, und die Abdeckungsanzeige werde am Ende der Testphase angehalten, während die Erweiterung in Wahrheit auf die kostenlose Community-Stufe zurückfällt.
• Telemetrie-Benachrichtigungen wurden von der falschen Domain gesendet. Der From:-Header war ein Postfach auf fucini.consulting, während der sendende Server fucini.software ist — genau die Übereinstimmung, vor der der eigene Kommentar der Einstellung warnt, und ein zuverlässiger Weg, Mail im Spamfilter oder rundheraus abgelehnt zu sehen.

Geändert

• Eine Datei, die der Bericht nennt, die es aber nicht gibt, wird dort gezeigt, wo sie hingehört — ausgegraut und mit Begründung. 0.2025.25 hat aufgehört, für solche Dateien Orte zu erfinden, was richtig war, ließ ihnen aber einen relativen Pfad, der überhaupt kein Ort ist — der Baum machte also weiterhin aus dessen erstem Segment ein Projekt, und die drei gelöschten Quellen eines Submoduls saßen in einem Phantom namens app neben genau dem Submodul, aus dem sie stammten. Die Unstimmigkeit war sichtbar, das war der Sinn, aber sie war an der falschen Stelle sichtbar und sagte nichts darüber, was nicht stimmte.
• Sie erscheint jetzt in dem Projekt, aus dem sie gemessen wurde, in dem Ordner, in den der Bericht sie stellt — gezeichnet im mittleren Grau des Themes und kursiv statt in der gewöhnlichen Vordergrundfarbe. Beim Überfahren erscheint der Pfad, den sie gehabt hätte, samt Hinweis, dass dort nichts ist — höchstwahrscheinlich nach der Erstellung des Berichts umbenannt oder gelöscht — und dass ihre Zahlen weiterhin zählen. Nichts wird verworfen, keine Summe verschiebt sich: die Zeile ist die eigene Aussage des Berichts, und das Ausgrauen ist das, was sie davon abhält, wie eine Zeile zu wirken, die sich öffnet.
• Die Vermutung bleibt in der Ansicht. Der gespeicherte Pfad der Datei ist weiterhin genau das, was der Bericht sagte, denn alles andere ist danach indiziert — die Anreicherung des externen Berichts vergleicht damit, die Telemetrie relativiert ihn, die annotierte Ansicht öffnet ihn — und ihnen einen vermuteten Ort zu geben hieße, Bekanntes gegen Erfundenes zu tauschen. Nur der Baum führt beides zusammen, und nur für einen Pfad, der keinen eigenen Ort benennt: ein absoluter Pfad, den es schlicht nicht gibt, behält, was der Bericht sagte, und wird an Ort und Stelle ausgegraut.

Behoben

• Die Abdeckung eines Submoduls landet dort, wo das Submodul wirklich liegt, und seine Zeilen lassen sich öffnen. Ein Git-Submodul erzeugt seinen eigenen Bericht neben seinem eigenen Baum, und gcovr schreibt darin <source>.</source> — „das Verzeichnis, in dem diese Datei liegt“ — mit Dateinamen wie app/Application.cpp darunter. Nichts verankerte dieses . irgendwo: Pfade wurden ein einziges Mal aufgelöst, nach dem Zusammenführen, und da wusste der Lauf nicht mehr, aus welcher Eingabe eine Datei stammte — die einzige verbleibende Basis war die Arbeitsbereichswurzel. Der Versuch mit <workspace>/app/Application.cpp fand nichts, jeder Pfad blieb relativ, und die Coverage-Ansicht zeichnete sie als Projekt namens app — benannt nach dem ersten Segment eines Pfades, der nie ein Ort war — dessen Zeilen alle irgendwohin kopierten und öffneten, wo keine Datei lag.
• Pfade werden jetzt pro Tracedatei aufgelöst, vor dem Zusammenführen. Ein relativer sourceRoot wird an das Verzeichnis seiner Tracedatei gebunden, sodass . neben der coverage.xml eines Submoduls genau dieses Submodul bedeutet. Findet das die Quellen nicht, sucht der Weg aufwärts von der Tracedatei — das übliche CMake-Layout schreibt Abdeckung mehrere Ebenen tief in build/, und welche der beiden Formen ein Projekt verwendet, steht nirgends im Bericht, also beantwortet es das Dateisystem statt einer Konfiguration. Der Weg endet an der Arbeitsbereichswurzel: darüber hinaus könnte ein bloßes src/main.c in einem Nachbar-Checkout mit gleichem Aufbau landen — eine falsche Antwort, die wie eine richtige aussieht. Ein bereits absoluter und vorhandener Pfad bleibt unangetastet, gewöhnliche lcov-Läufe ändern sich also nicht.
• Ein Submodul bleibt in der Coverage-Ansicht ein eigenes Projekt. Dateien, die nun innerhalb des Arbeitsbereichs aufgelöst werden, wären sonst in dessen eigenen Baum gefallen — die Ordner des Submoduls verschränkt mit denen des Elternprojekts und seine Zahlen zur Gesamtsumme addiert, als wäre eine Codebasis zweimal gemessen worden. Jede Datei merkt sich die Wurzel, von der aus sie gemessen wurde, und die Ansicht gruppiert danach; ein Submodul behält also eigene Überschrift und eigene Summen, obwohl es im geöffneten Ordner liegt. Ein Lauf mit ohnehin absoluten Pfaden hat keine solche Wurzel und wird gruppiert wie zuvor.
• Eine Datei, die der Bericht nennt, die es aber nicht mehr gibt, wird weiterhin als fehlend gemeldet. Sie erhält keinen plausiblen Pfad, an dem sie nicht liegt: Ein Bericht, der inzwischen gelöschte Dateien nennt, ist ein veralteter Bericht, und sie an erfundenen Orten zu zeichnen würde das verbergen. Jede wird im Ausgabekanal unter FUCINI_REMAP_001 genannt, mit dem Pfad, den sie gehabt hätte.

Geändert

• Ein Platz, der verschwindet, sagt jetzt warum. Jeder Entzug zeigte dieselbe Zeile — Ihr Lizenzplatz in diesem Plan ist nicht mehr aktiv — und das liest sich wie ein Vorwurf an die falsche Person. Ein Teamabonnement, das unter die Zahl der genutzten Plätze reduziert wird, gibt den Überschuss nun nach einer Karenzzeit frei, und wer einen Platz verliert, hat nichts getan, außer der zu sein, der ihn am längsten nicht genutzt hat. Wo der Lizenzserver etwas Nützliches zu sagen hat, sagt die Erweiterung es: Ein Platz, der für ein reduziertes Abonnement freigegeben wurde, erklärt genau das und verweist auf die Person, die das Abonnement verwaltet — Neuen Schlüssel anfordern wird weiterhin angeboten, denn der Weg zurück ist real: Der Pool hat Platz, sobald diese Person einen freigibt.
• Ein beendetes Abonnement bietet keine Schaltfläche. Aus einem abgelaufenen Abonnement lässt sich kein neuer Schlüssel ausstellen, also konnte die einzige Aktion dieser Benachrichtigung nur scheitern — und das liest sich wie eine defekte Erweiterung statt wie ein beendetes Abonnement. Jetzt sagt sie, was passiert ist, und belässt es dabei. Jeder Grund, den dieser Build nicht kennt, behält die allgemeine Formulierung: Der Lizenzserver wird laufend ausgeliefert, eine installierte Erweiterung nicht — einem unbekannten Grund zu begegnen ist also der Normalfall und nicht der Sonderfall. Es erscheint nie eine rohe Kennung, und es bleibt nie stumm. Beide neuen Meldungen sind in alle siebzehn Sprachen übersetzt.

Hinzugefügt

• Der Lauf kann die Erweiterung jetzt verlassen — in sechs weiteren Formaten. Bisher führten nur zwei Wege hinaus: Fucini JSON, das außer der Erweiterung nichts liest, und ein HTML-Bericht, den maschinell überhaupt nichts liest. Export Coverage Report... öffnet eine Formatauswahl und schreibt den aktiven Lauf als CSV pro Datei (abgedeckt/gesamt/Prozent für Zeilen, Zweige, Funktionen, MC/DC, Regionen und Instanziierungen, schlechteste zuerst, mit einer TOTAL-Zeile), als CSV pro Funktion (Aufrufzähler, ob sie lief, ungetestete Zweige darin, MC/DC-Paare), als Markdown-Zusammenfassung für einen Pull Request, als LCOV-Tracefile, Cobertura-XML, SARIF oder als eigenständiges SVG-Badge für eine README. Zu finden in der Befehlspalette, in der Titelleiste der Ansicht „Abgedeckte Dateien“ neben Generate Full HTML Report und im Schnellmenü der Statusleiste, sobald quickActions.exportReport aktiv ist.
• Jetzt ein Konverter, nicht nur ein Betrachter. Die Erweiterung liest bereits lcov, llvm-cov JSON, Cobertura, JaCoCo, Istanbul/nyc und SimpleCov; mit den LCOV- und Cobertura-Schreibern geht es nun auch in die andere Richtung. Laden Sie einen JaCoCo-Bericht oder mehrere zu einem Lauf zusammengeführte Berichte und erzeugen Sie daraus das eine Tracefile, das genhtml, Codecov, Coveralls und SonarQube alle akzeptieren — oder das XML, das Jenkins, GitLab und Azure DevOps nativ einlesen. Beide durchlaufen die eigenen Parser der Erweiterung, und Zeilenbereiche werden pro Zeile aufgelöst, damit die geschriebenen LF/LH mit dem angezeigten Prozentwert übereinstimmen statt ihn zu nähern.
• Jeder Schreiber sagt, was er verwirft. Alle außer den CSVs sind verlustbehaftet, und zwar stillschweigend: MC/DC, Code-Regionen und C++-Instanziierungen haben in LCOV, Cobertura oder SARIF keine Entsprechung, und Cobertura hält fest, wie viele Bedingungen einer Zeile abgedeckt waren, nicht welcher Zweig. Fucini JSON und die beiden CSVs bleiben die Formate, die alles Gemessene tragen. In den CSVs bleiben die Zellen einer Metrik, die der Lauf nicht hat, leer statt null — eine leere Zelle sagt „dieses Werkzeug hat keine Zweigdaten gemeldet“, eine 0 sagt „kein einziger Zweig wurde getroffen“, und eine Tabellenkalkulation kann das hinterher nicht mehr unterscheiden. Alles, was eine Tabellenkalkulation sonst als Formel ausführen würde — ein Feld, das mit =, +, - oder @ beginnt, also jeder npm-Scope-Pfad — wird vor dem Schreiben zitiert und entschärft.
• SARIF annotiert das Diff; das Badge braucht kein Netz. Ungetestete Bereiche werden auf Stufe note gemeldet, nicht warning: ungetesteter Code ist eine Aussage über die Testsuite, und Code-Scanning behandelt eine Warnung als etwas, das blockieren soll — die blockierende Schranke bleibt Check Coverage Thresholds. Das Badge wird hier gezeichnet statt von shields.io geholt, funktioniert also auch in einem abgeschotteten oder selbst gehosteten Repository, und nimmt seine Farbe aus derselben colorScale wie Randmarkierungen und Statusleiste. In der kostenlosen Community-Edition öffnet sich die Auswahl und beide CSVs funktionieren, begrenzt auf 20 Exporte pro Tag wie Export Fucini JSON; die Austauschformate gehören zur kostenpflichtigen Stufe — auf derselben Linie wie bisher: die eigenen Zahlen lesen ist frei, eine CI-Pipeline füttern nicht.

Behoben

• Eine Datei, in der es nichts zu instrumentieren gibt, wird nicht mehr als zu 100 % abgedeckt gemeldet. Ein reiner Deklarations-Header — Prototypen, ein Makro, Include-Guards — hat keine Funktionsrümpfe, also erzeugt der Compiler für ihn keine Coverage-Zuordnung, und alles, was null durch null teilt, antwortet mit 100 %. Er stand grün im Baum, neben Code, der wirklich getestet worden war. Beide Leser nehmen nun die Summen des Werkzeugs selbst als Auskunft der Datei über sich — LF/FNF/BRF in lcov, den summary-Block im llvm-cov-JSON — und eine Datei, deren sämtliche Summen null lauten, bleibt aus dem Lauf heraus, statt bewertet zu werden. Die zeilenweisen Einträge darunter werden bewusst ignoriert: Die Expansion eines Makros wird der Zeile zugeschrieben, die es definiert, während die Zählung zur Zeile gehört, die es verwendet — in einer anderen Datei; genau diese geliehene Zeile war der einzige Grund, warum ein solcher Header je gemessen aussah. Auch die Gesamtsummen verlieren sie, sodass die Kennzahl etwas niedriger und viel ehrlicher ausfällt. Jeder ausgelassene Pfad wird im Ausgabekanal benannt, und ein Bericht, in dem jede Datei reine Deklaration ist, behält sie alle.

Geändert

• Das Auswählen einer Abdeckungsdatei ergänzt das bereits Geladene, statt es zu ersetzen. Ein Build, der pro Modul einen Bericht schreibt, hat keine einzelne Datei zum Festlegen, und die Wahl des zweiten Modulberichts entlud stillschweigend den ersten. Der Dialog nimmt jetzt mehrere Dateien auf einmal, jede Auswahl kommt hinzu, und alles Gewählte wird zu einem Lauf zusammengeführt — im Panel unter dem eigenen Namen jedes Projekts gezeichnet. Die Überwachung folgt allen, und ein neu erzeugter Bericht nimmt die anderen nicht mehr vom Bildschirm. Show Loaded Coverage Files endet mit Ausgewählte Dateien entladen, was zur gewöhnlichen Suche zurückkehrt.
• Der Support hat eine Adresse auf der Produktdomäne: support@fucini.software. Wenn die Aktivierung nicht von selbst abschließen kann, nannten das Lizenzfenster und die Meldung mit dem Anforderungscode bisher eine fucini.consulting-Adresse — eine andere Domäne als jeder andere Link der Erweiterung, und eine, die sich wie ein anderes Unternehmen liest. license@fucini.software bleibt unverändert: Von dort kommen Schlüssel, es ist kein Postfach zum Hinschreiben.

Hinzugefügt

• Jeder Baum in der Coverage-Ansicht sagt jetzt, zu welchem Projekt er gehört. In 0.2025.19 bekam ein zusammengeführter Lauf einen benannten Block je Projekt, ein gewöhnlicher Lauf zeichnete aber weiterhin einen nackten Baum — ein auf seinen eigenen Ordner zurückgeschnittener Arbeitsbereich öffnete also auf src, ohne dass darüber stand, welches src. Jeder Baum trägt nun seine Wurzel: die Ordner oberhalb des Projekts in der gedämpften Farbe, der eigene Ordner des Projekts dahinter in voller Farbe. Ein auf den Arbeitsbereichsordner zurückgeschnittener Baum sagt weiterhin, worauf er zurückgeschnitten wurde, und zwei zu einem Lauf zusammengeführte Codebasen werden nie als ein Baum gelesen. Es ist eine Überschrift und keine Zeile — dort gibt es nichts aufzuklappen, und die Ordner darunter klappen genau wie zuvor. In einem schmalen Panel kürzen sich die führenden Verzeichnisse zuerst, sodass der Ordner, der das Projekt tatsächlich benennt, als Letztes verschwindet; ein Hover zeigt den ganzen Pfad.

Hinzugefügt

• Die Zeilen der Coverage-Ansicht haben das Kontextmenü des Explorers. Ein Rechtsklick auf eine Datei oder einen Ordner öffnete bislang das Ausschneiden/Kopieren/Einfügen der Webview — drei Einträge ohne etwas, worauf sie hätten wirken können. Jetzt öffnet sich das echte Menü von VS Code: Öffnen, Open to the Side, Öffnen mit…, Reveal in Explorer View, Reveal in File Explorer, Open in Integrated Terminal, Im Ordner suchen… für Ordner sowie Copy Path / Copy Relative Path — unter Windows daneben die Varianten mit Schrägstrichen, wo sich beide Formen unterscheiden. Die Schaltfläche ⋯ und ihr Menü bleiben unverändert und bilden den letzten Eintrag des neuen Menüs.

Geändert

• Eine Metrik, für die Ihre Tracefile keine Daten enthält, wird nicht mehr bewertet. Ein MC/DC-Schwellwert ohne MC/DC im Build galt als Fehlschlag — eine Datei mit 100 % in jeder tatsächlich gemessenen Metrik stand so unter einer Karte mit „3 von 5 erfüllt“, gegen eine Latte, die nichts in dieser Tracefile je hätte reißen können. Metriken ohne Daten werden jetzt überall übersprungen, wo ein Urteil entsteht: in der Statusleiste je Datei, in der Karte des gesamten Laufs, im Banner des annotierten Quellcodes und im HTML-Bericht. Check Coverage Thresholds benennt eine fehlende Metrik weiterhin ausdrücklich — dort gehört das hin.
• Dateien ohne etwas Messbares erscheinen nicht mehr in der Coverage-Ansicht. Ein Header voller Deklarationen, eine Datei mit lauter Re-Exporten, ein reines Typmodul: kein Test, den Sie schreiben, ändert deren Zahl, und beim Öffnen erscheinen überhaupt keine Metriken. In 0.2025.19 bekamen sie einen Strich; jetzt stehen sie schlicht nicht mehr in der Liste, und Ordner, die dadurch leer bleiben, verschwinden mit. Ein Lauf, in dem nichts messbar ist, listet weiterhin alles.

Behoben

• Ein Laufwerksbuchstabe konnte den Baum weiterhin anführen. Bei Coverage, deren Pfade nicht unter dem geöffneten Arbeitsordner liegen — eine zusammengeführte Tracefile aus einem anderen Projekt oder ein Fenster ohne geöffneten Ordner — begann der Baum bei W:, unter Linux und macOS sogar bei einer Zeile ganz ohne Namen: eine Zeile mit genau einem Kind, aufklappbar ohne Zweck. Die Wurzel des Dateisystems wird jetzt nie mehr gezeichnet, wie die Pfade auch aussehen, und jede Zeile trägt weiterhin ihren echten absoluten Pfad für Menü und Editor.

Hinzugefügt

• Ein Zeilenmenü für jede Datei und jeden Ordner in der Coverage-Ansicht. Die Schaltfläche am Ende einer Zeile kopiert deren Pfad in jeder der vier Formen, die ein Editor, eine Shell oder ein Prompt brauchen kann — absolut oder relativ zum Arbeitsbereich, mit den Trennzeichen des Systems oder mit Schrägstrichen — und bietet Reveal in File Explorer und Open in Integrated Terminal, wobei eine Datei das Terminal in ihrem eigenen Verzeichnis öffnet. Die Schrägstrich-Einträge erscheinen nur dort, wo sie sich von der systemeigenen Form unterscheiden; unter Linux und macOS ist das Menü daher zwei Einträge kürzer. Einen Pfad zu kopieren hieß bisher, dieselbe Datei ein zweites Mal im Explorer zu suchen.
• Schaltflächen zum Ein- und Ausklappen aller Ordner über dem Baum. Alles einzuklappen und dann den einen Ordner zu öffnen, um den es geht, ist der schnellste Weg durch einen großen Baum — und kostete zuvor einen Klick pro Ordner. Was so eingeklappt wird, merkt sich die Ansicht genau wie einen von Hand geschlossenen Ordner; ein Neuladen macht es nicht rückgängig.
• Ein zusammengeführter Lauf über mehrere Projekte zeichnet jetzt jedes Projekt einzeln, unter seinem eigenen Namen. Eine Tracedatei aus einer zweiten Codebasis hängte ihre Ordner bisher an denselben Baum wie die des Arbeitsbereichs, sodass src zweimal auftauchte, ohne zu sagen warum, und sich die Verzeichnisse beider Projekte alphabetisch vermischten. Jedes Projekt erhält nun einen eigenen benannten Block, durch eine Linie getrennt, das des Arbeitsbereichs zuerst. Ein Lauf über nur ein Projekt bleibt unverändert und trägt keine Überschrift — es gäbe nichts, wovon er sich abheben müsste.

Behoben

• Eine Datei ohne ausführbaren Inhalt wurde als zu 0% abgedeckt gemeldet. Ein Modul, das nur aus export *-Reexporten oder nur aus Typdeklarationen besteht, kompiliert zu nichts, was ein Coverage-Werkzeug messen kann — die Tracedatei enthält dafür also keine einzige Anweisung. Die Coverage-Ansicht bewertete das mit 0% und stellte die Datei rot neben Code, der tatsächlich ungetestet ist, obwohl es dafür nichts zu testen gibt; der Explorer versah dieselbe Datei derweil mit einem grünen 100%, weil eine leere Gesamtzahl sich als "alles von nichts abgedeckt" liest. Keine der beiden Zahlen stimmte, und keine wird mehr angezeigt: Die Zeile im Panel erhält einen Gedankenstrich und einen gestrichelten Rahmen mit einem Tooltip, der den Grund nennt, und das Explorer-Abzeichen entfällt. Ein Ordner, der nur solche Dateien enthält, bleibt ebenfalls unbewertet. Eine Datei, die 0% von etwas tatsächlich Gemessenem hat, zeigt weiterhin 0% — der Strich bedeutet "nichts zu messen", nicht "gemessen und verfehlt".
• Zeilen aus einem zusammengeführten Projekt zeigten an die falsche Stelle. Ihre Pfade wurden vom Stamm des Arbeitsbereichs aus gebildet statt von ihrem eigenen, sodass das Zeilenmenü für eine Datei außerhalb des Arbeitsbereichs einen Pfad kopierte — und "Reveal in File Explorer" einen Pfad öffnete —, an dem die Datei nie war. Sie tragen jetzt den Stamm, aus dem sie tatsächlich stammen.

Geändert

• Die Coverage-Ansicht zeichnet den Stamm des Arbeitsbereichs nicht mehr. Der Baum begann an der Wurzel des Dateisystems und lief durch jeden Ordner oberhalb des Projekts — das Laufwerk, dann das Verzeichnis mit Ihren Projekten, dann das Projekt selbst — bevor der erste Ordner kam, der wirklich Ihrer war. Das waren mehrere Einrückungsebenen, in jeder Zeile, die wiederholten, was der Fenstertitel längst sagte. Pfade beginnen jetzt beim Arbeitsbereichsordner. Kopiert und geöffnet wird nach wie vor der vollständige absolute Pfad.

Behoben

• Ordner, die Sie in der Coverage-Ansicht zugeklappt hatten, klappten bei jedem Neuladen wieder auf. Die Überwachung ist standardmäßig eingeschaltet, sodass ein Build, der Coverage neu erzeugt, das Panel neu zeichnet — und weil jeder Ordner aufgeklappt gezeichnet wurde, hielt das Zuklappen nur bis zum nächsten Build. Bei einem großen Baum hieß das, dieselbe Arbeit mehrmals pro Stunde zu erledigen. Das Panel merkt sich jetzt, welche Ordner Sie geschlossen haben, und lässt sie geschlossen. Ein Verzeichnis, das in einem späteren Lauf zum ersten Mal auftaucht, erscheint weiterhin aufgeklappt wie jedes andere: Gemerkt wird die bewusste Handlung des Schließens, nicht der Standardzustand.
• Das Ausschalten der Telemetrie stoppte den Deinstallations-Ping nicht. Dieser Ping wird von einem kleinen eigenständigen Skript gesendet, das VS Code beim Deinstallieren ausführt. Es hat keinen Zugriff auf die VS Code-API und kann Ihre Einstellungen nicht lesen; das Einzige, was ihm je sagt, nichts zu senden, ist das Fehlen einer Datei, die die Erweiterung schreibt, solange die Telemetrie eingeschaltet ist — und diese Datei wurde beim Ausschalten der Telemetrie nie entfernt. Wer sie eingeschaltet und später wieder ausgeschaltet hatte, hätte beim Deinstallieren trotzdem seinen Betriebssystem-Benutzernamen, Hostnamen und sein Home-Verzeichnis gesendet. Die Datei wird jetzt gelöscht, sobald die Telemetrie aus ist.
• Eine Pro-Verlängerung konnte Erfolg für einen Schlüssel melden, den Sie gerade ersetzt hatten. Die stille Verlängerung las Ihren konfigurierten Schlüssel zweimal: einmal, um zu entscheiden, ob verlängert wird, und danach noch einmal, um zu entscheiden, ob etwas gemeldet wird. Wurde während einer laufenden Verlängerung ein neuer Schlüssel eingefügt, sah der zweite Lesevorgang einen anderen Schlüssel, und die Meldung „Ihr Pro-Abonnement wurde verlängert“ beschrieb den ersetzten. Der Schlüssel wird jetzt nur einmal gelesen.

Geändert

• Jedes Modul der Erweiterung ist jetzt durch eigene Tests abgedeckt. Für ein Werkzeug, dessen ganze Aufgabe es ist, Ihnen zu zeigen, was Ihre Tests tatsächlich erreichen, schien es das wert, das gründlich zu tun: 53 der 54 Quelldateien stehen bei 100% für Anweisungen, Zweige, Funktionen und Zeilen, die verbleibende — die VS Code-Anbindungsschicht — bei 95% ihrer Funktionen. Beim Schreiben kamen die oben genannten Fehler zutage, dazu gut zwanzig Schutzabfragen, die nie ausgeführt werden konnten: Rückfallpfade hinter Prüfungen, die sie bereits ausgeschlossen hatten, die wie Sicherheitsnetze aussahen und nichts auffingen. Sie wurden entfernt, statt sie mit einem Test zu überdecken, der nicht fehlschlagen konnte.

Geändert

• Die optionale Umfrage wartet jetzt, bis Sie die Erweiterung wirklich genutzt haben, und fragt zu einem besseren Zeitpunkt. Bisher zählte sie Kalendertage seit der Installation und maß damit, wie lange die Installation her ist — nicht, ob Sie die Erweiterung je bei der Arbeit gesehen haben. Eine einen Monat lang unberührte Installation wurde gebeten, ein Produkt zu bewerten, das ihr nie etwas gezeigt hatte. Nun zählen echte Coverage-Ladevorgänge mit, und die Umfrage erscheint nicht mehr während des Editorstarts: Sie wartet auf einen erfolgreichen Ladevorgang. Nach einem Jahr folgt eine dritte und letzte Einladung, denn zwei innerhalb eines Quartals schlossen jeden dauerhaft aus, der gerade beschäftigt war.
• Die niederländische Übersetzung ist nicht mehr förmlich. Sie sprach durchgehend mit „u“ an, was für ein Entwicklerwerkzeug steif klingt und zu nichts anderem an der Stimme des Produkts passte. Alle niederländischen Texte verwenden jetzt „je“ — Satz für Satz neu geschrieben, da die Änderung die Verbformen mitzieht.

Geändert

• Das Aktivierungsformular fragte Einzelentwickler nach einem „Company code“. Wer Pro oder Pro Plus als Einzelperson kauft, erhält einen Code aus dem eigenen Abonnement — dahinter steht keine Firma, und die Frage danach lässt vermuten, man sei im falschen Formular. Das Feld heißt jetzt Subscription code für Pro und Pro Plus und bleibt Company code für Business und Enterprise, wo ein Team tatsächlich einen gemeinsamen Code hat. Die Hinweise darunter waren bereits pro Plan formuliert; nur die Beschriftung war allgemein geblieben.

Behoben

• Der erzeugte HTML-Bericht bewertete Ihren Code an 100 %, ganz gleich welche Schwellenwerte Sie gesetzt hatten. Die Status-Spalte prüfte jede Metrik gegen eine verborgene 100 — ein Projekt, das seine Grenzen auf 80 setzte und sie einhielt, sah ein grünes COMPLIANT-Banner direkt über einer Spalte roter Kreuze, für denselben Lauf, auf derselben Seite. Die Metrik-Legende ebenso. Beide verwenden jetzt Ihre konfigurierten Schwellenwerte, und wo keiner gilt, zeigen sie einen gedämpften Gedankenstrich statt eines erfundenen Urteils.
• Das Compliance-Banner behauptete mehr, als es geprüft hatte. Es lautete stets „alle konfigurierten Schwellenwerte erreicht", auch im Standardmodus, der nur den gewichteten Score prüft — ein Lauf konnte also behaupten, jeder Schwellenwert sei erreicht, während einer in der Tabelle darunter sichtbar durchfiel. Jeder Modus nennt nun die Regel, die er tatsächlich angewandt hat.
• Die README behauptete, die Erweiterung „läuft kostenlos bis 2026-12-31". Dieses Datum gibt es im Produkt nicht. Eine frühere Version korrigierte diese Aussage in den Einstellungsbeschreibungen, übersah aber die README — das Erste, was man im Marketplace liest. Dort steht jetzt, was wirklich passiert: 14 Tage Testphase ab der ersten Nutzung, danach die kostenlose Community-Stufe, ohne ein Datum, nach dem etwas endet.

Geändert

• Die beiden Editionen sehen im Marketplace nicht mehr identisch aus. Pro und Community werden aus einem Quellbaum gebaut, und bis jetzt galt das auch für das Symbol — die beiden Einträge waren also dasselbe Bild mit unterschiedlicher Beschriftung, nebeneinander in denselben Suchergebnissen. Jede Edition hat jetzt ihr eigenes: dieselbe Grafik mit einem farbigen Band am unteren Rand, Türkis für Pro und Schiefergrau für Community. Das Wort unterscheidet sie, wenn das Symbol groß dargestellt wird; in einer Suchergebniszeile ist das Wort zu klein zum Lesen, das übernimmt dann die Farbe.

Behoben

• Die annotierte Ansicht zu öffnen hindert Sie nicht mehr daran, sie erneut zu öffnen. Das Panel der annotierten Quelle ist ein Webview und kein Texteditor, also sah die Erweiterung, solange es den Fokus hatte, keine „aktuelle Datei" — und Open Annotated Source antwortete dort mit „öffnen Sie zuerst eine Datei mit geladener Abdeckung", und zwar jemandem, der gerade auf die annotierte Ansicht einer Datei mit Abdeckung blickte. Jetzt greift der Befehl auf die Datei hinter dem Panel zurück, das Sie vor sich haben. Derselbe Block übersprang außerdem stillschweigend die erneute Prüfung, für die ein zweiter Aufruf existiert: Ist ein llvm-cov-HTML-Bericht konfiguriert, schaltet genau dieser zweite Aufruf das Panel auf die Seite dieses Berichts um — war Ihr Coverage-Build also erst nach dem Öffnen des Panels fertig, war das vom Panel aus nicht erreichbar.

Hinzugefügt

• Ein bezahltes Pro-Abonnement verlängert sich jetzt selbst. Jeder Aktivierungsschlüssel gilt genau so lange wie der bezahlte Zeitraum. Die Teampläne übernehmen eine Verlängerung beim nächsten Check-in, individuelles Pro meldet sich aber nie — es arbeitet vollständig offline —, also brachte nichts die Verlängerung dorthin, und der Schlüssel eines Monatsabonnenten wäre etwa monatlich abgelaufen, so treu er auch zahlte. Die Erweiterung fordert nun still einen neuen Schlüssel an, nur in den Tagen um den eigenen Ablauf und nur, wenn sie den Code besitzt, der ein bezahltes Abonnement belegt. Offline zu sein kostet in diesem Zeitraum nichts: Der Schlüssel läuft weiter, bis er wirklich abläuft, und der nächste Versuch danach stellt ihn wieder her.
• Die Aktivierung aus der Kauf-E-Mail ist ein Klick. Der Link übergibt der Erweiterung Plan und Code direkt, statt VS Code zu öffnen, den Befehl zu suchen und den Code von Hand einzufügen. Vor der Belegung eines Platzes wird immer gefragt. Den Code selbst einzugeben funktioniert weiterhin genauso — der Link ist eine Abkürzung, nie der einzige Weg — und er funktioniert auch in der Community-Version.

Behoben

• Eine Einstellungsbeschreibung behauptete, die Erweiterung sei "bis 2026-12-31 kostenlos". Dieses Datum kommt im Produkt nirgends vor. Tatsächlich gibt es eine 14-tägige Testphase ab der ersten Nutzung, danach fällt die Erweiterung auf die kostenlose Community-Stufe zurück. Genau das steht dort nun, in jeder Sprache.
• Die Schwellenwert-Einstellungen nennen nicht mehr die Version, in der sich ihre Standardwerte änderten — eine Versionsnummer mitten im Satz beantwortet eine Frage, die beim Lesen einer Einstellungsbeschreibung niemand stellt.
• Mehrere übersetzte Beschreibungen nannten einen Befehl, den kein übersetztes VS Code anzeigt. Sie verwiesen mit dem englischen Namen auf den Aktivierungsbefehl, sodass alle, die nicht auf Englisch arbeiten, in der Befehlspalette nach einem Text suchten, der dort nicht steht.

Behoben

• Ein Projekt ohne MC/DC-Entscheidungen konnte 0 % Gesamtabdeckung anzeigen. Manche Werkzeuge melden einen MC/DC-Abschnitt auch dann, wenn es darin nichts zu messen gibt, und das wurde als „0 % abgedeckt“ statt als „nichts abzudecken“ gelesen. Da die Gesamtbewertung auf null fällt, sobald eine Kennzahl null ist, konnte ein vollständig abgedecktes Projekt 0 % anzeigen. Eine Kennzahl ohne Messbares fließt jetzt gar nicht mehr in die Bewertung ein, und ihre Zeile entfällt, statt als „0 / 0 Bedingungen abgedeckt“ zu erscheinen.
• Der Lizenzstatus ist jetzt in allen 17 Sprachen übersetzt. Er blieb überall englisch, und da er in bereits übersetzten Sätzen steht, ergab das eine halb übersetzte Zeile in der Statusleiste, in Benachrichtigungen und im Bereich „Abgedeckte Dateien“.
• Auch die Ansicht „Annotierter Quelltext“ und die Abdeckungs-Hovers sind jetzt übersetzt — die Tabelle mit der Konformitätsaufschlüsselung, die Navigationsschaltflächen samt Tooltips sowie die Zweig- und MC/DC-Details beim Überfahren mit der Maus.

Geändert

• Ein kostenpflichtiges Pro-Abonnement lässt sich jetzt mit einem eigenen Code aktivieren. Die Planliste in der Schlüsselanforderung hat einen Pro-Eintrag erhalten, sodass der Code, der zu einem Pro-Abonnement gehört, endlich irgendwo eingegeben werden kann. Einzelne Pro-Schlüssel funktionieren weiterhin vollständig offline und nehmen nach der Aktivierung nie Kontakt zum Server auf.
• Das Symbol in der Aktivitätsleiste ist größer und besser erkennbar neben den integrierten Symbolen.
• Der Wechsel zur Community-Edition installiert diese jetzt von fucini.software. Zuvor wurde der Marketplace versucht, wo die Community-Edition nicht veröffentlicht ist — der Wechsel konnte Sie also ganz ohne Erweiterung zurücklassen.

Geändert

• Ein abgelaufenes Abonnement landet jetzt auf der kostenlosen Stufe — wenn ein individueller Aktivierungsschlüssel auslief, forderte die Erweiterung Sie endlos zur Verlängerung auf. Sich gegen eine Verlängerung zu entscheiden, ist ein normales Ende eines Abonnements und kein Fehler, daher geht sie nun stattdessen in die dauerhafte, kostenlose Community-Stufe über. Team-Tarife bleiben bewusst unberührt: Ein abgelaufener Pro Plus-, Business- oder Enterprise-Schlüssel wird weiterhin als abgelaufen gemeldet, denn dort muss ein Administrator ihn verlängern, und das gesamte Unternehmen stillschweigend auf die kostenlose Stufe herabzustufen würde das verschleiern.

Behoben

• Das Abschalten der Telemetrie wird jetzt in jedem Fall beachtet. Ein Codepfad konnte die Prüfung überspringen, wenn der interne Modus für detaillierte Diagnose der Erweiterung aktiv war. Dieser Modus ist in jedem veröffentlichten Build abgeschaltet, sodass sich nie ein Release so verhalten hat, doch die Prüfung erfolgt jetzt bedingungslos.
• Einstellungen greifen sofort, statt auf ein Neuladen zu warten. Das Ändern von Pfad-Remapping, Kommentarausschluss, git-diff-Filterung oder der Summen für ausgeschlossene Dateien lädt die Coverage jetzt unmittelbar neu — insbesondere das Pfad-Remapping, denn genau zu dieser Einstellung greifen Sie ja, weil die Pfade nicht zusammenpassen.
• „Unlock Full Features“ und „Switch to Community“ konnten auf halbem Weg stehen bleiben, ohne das mitzuteilen. Beide laufen jetzt vollständig durch.
• Ihr Aktivierungsschlüssel bleibt an dieselbe Maschinenidentität gebunden. Auf manchen Systemen konnte diese Identität zuvor zwischen Sitzungen neu erzeugt werden, was einen bereits ausgestellten Schlüssel ungültig machte.

Hinzugefügt

• Vollständige Übersetzungen in allen 17 mitgelieferten Sprachen — rund hundert der neueren Oberflächentexte, darunter die Dialoge für Aktivierung und Lizenzierung, die optionale Feedback-Umfrage, der Community-Freischaltungsablauf und die Benachrichtigungen zur Selbstaktualisierung, fielen in jedem nicht-englischen Bundle noch auf Englisch zurück. Alle 17 Sprachen decken nun die vollständige Laufzeitoberfläche der Erweiterung ab.

Geändert

• Aufräumdurchgang durch Quellcode-Kommentare, die Dokumentation der Build-Skripte und die Dateiliste für die Paketierung. Der Satz der in der Erweiterung ausgelieferten Dateien bleibt unverändert; keine funktionalen Änderungen und keine Verhaltensänderungen.

Behoben

• Die gleichzeitige Installation der Pro- und der Community-Edition konnte eine von beiden beim Start zum Absturz bringen — sie registrieren dieselben Befehle und dieselbe Ansicht der Coverage-Dateien. Das wird nun vorab erkannt: Ist die jeweils andere Edition ebenfalls installiert, bricht die Aktivierung sauber mit einem Hinweis ab, eine der beiden zu deinstallieren, statt mit einem unerklärten Aktivierungsfehler.

Wartungs-Release; keine funktionalen Änderungen.

Eine dauerhaft kostenlose Stufe, Team-Tarife, die sich einen Seat-Pool teilen, und eine separate Community-Edition der Erweiterung.

Hinzugefügt

• Eine dauerhafte, kostenlose Community-Stufe — statt eines harten Stopps nach Ablauf der 14-tägigen Testphase geht die Erweiterung nun in Community über: alle Funktionen außer MC/DC, ein begrenzter monatlicher Vorgeschmack auf den Full HTML Report und die dauerhaften Annotated-Source-Ansichten, großzügige Tageslimits für eine Handvoll automatisierbarer Aktionen und alles Übrige unbegrenzt.
• Alle Funktionen kostenlos freischalten — ein neuer Befehl „Unlock Full Features“ tauscht detaillierte Nutzungstelemetrie gegen eine vollständige, uneingeschränkte Freigabe ein, jederzeit umkehrbar. Eine optionale Feedback-Umfrage in der App belohnt stattdessen mit einem 30-tägigen Schlüssel mit vollem Funktionsumfang, ganz ohne Bedingungen.
• Team-Tarife: Pro Plus, Business und Enterprise — diese teilen sich einen Seat-Pool (ein Firmencode plus eine Anzahl von Seats) statt eines Schlüssels pro Rechner, mit einem Check-in im Hintergrund, der die Freigabe eines Seats aktuell hält und einen entzogenen oder reduzierten Seat automatisch meldet.
• Fucini Coverage Studio Community — ein separater, eigener Eintrag, aus demselben Quellcode gebaut, in dem der Code für Testphase, Aktivierung und Team-Tarife der kostenpflichtigen Stufen tatsächlich fehlt statt nur verborgen zu sein. Siehe die Download-Seite.

Geändert

• Die Erzeugung des Full HTML Report und die dauerhaften Annotated-Source-Ansichten (einfach und nebeneinander) sind in der Community-Basis nun Funktionen der kostenpflichtigen Stufen — nur die Umschaltansicht an Ort und Stelle bleibt erhalten, monatlich begrenzt wie zuvor. Die Freischaltung gewährt weiterhin alles davon.
• Eine Warnung zum Nutzungslimit auf der Community-Stufe bietet nun beide Wege in einer einzigen Abfrage an: kostenpflichtige Tarife ansehen oder per Telemetrie freischalten.

Behoben

• Detaillierte, potenziell identifizierende Telemetrie (Betriebssystem-Benutzername, Home-Verzeichnis, CPU-/RAM-Daten, Netzwerkschnittstellen sowie der vollständige Bericht- und Quellcode-Inhalt) kann künftig ausschließlich von Community oder von einer telemetriegebundenen kostenlosen Freigabe gesendet werden — niemals von einer kostenpflichtigen Lizenz Pro, Pro Plus, Business oder Enterprise, unabhängig von den lokalen Telemetrie-Einstellungen.
• Eine Installation, die bereits auf einer früheren Version lief, erhält nicht länger allein wegen des Upgrades eine neue Testphase — sie landet nun korrekt auf der Community-Stufe, wenn ihre alte Testphase bereits abgelaufen war.
• Die Update-Benachrichtigung, der Download-Fortschritt und die Fehlermeldungen zeigen jetzt die einfache Version Major.Year.Minor (passend zu dem, was die Extensions-Ansicht von VS Code anzeigt), statt die interne Build-Nummer preiszugeben, z. B. 0.2024.6 statt 0.2024.6.2.

Aktivierungsschlüssel können einzelne Funktionen jetzt getrennt begrenzen, und Lizenzadministratoren können über das Dashboard von Hand einen fein abgestimmten Schlüssel ausstellen.

Hinzugefügt

• Nutzungslimits pro Funktion — Aktivierungsschlüssel können jetzt jede Funktion bzw. Aktion einzeln begrenzen (zum Beispiel HTML-Berichtsexporte auf 1 pro Monat), statt eines gemeinsamen Limits für das Laden von Coverage. Bestehende Schlüssel funktionieren unverändert weiter.
• Manuelle Schlüsselausstellung — Lizenzadministratoren können jetzt von Hand einen Schlüssel für einen Anfragecode ausstellen, der außerhalb des Fragebogens im Editor eingegangen ist, und dabei genau festlegen, welche Funktionen freigegeben werden, ein Ablaufdatum sowie Limits pro Funktion; der Schlüssel wird automatisch per E-Mail versendet, wenn eine Adresse angegeben wurde.

Behebt einen Caching-Fehler, durch den neue Versionen für Benutzer hinter bestimmten Unternehmens-Proxys unsichtbar bleiben konnten.

Behoben

• Zuverlässigkeit des Selbstaktualisierungs-Feeds — das Update-Manifest wird jetzt mit einem strikten No-Cache-Header ausgeliefert, sodass ein zwischengeschalteter Caching-Proxy zwischen fucini.software und dem Leser keine veraltete Kopie mehr ausliefern kann, die neue Versionen verbirgt.

Ein kleines Wartungs-Release: einige kleinere Fehlerbehebungen und Leistungsverbesserungen.

Behoben

• Fehlerbehebungen — kleinere Fehlerbehebungen und Stabilitätsverbesserungen.
• Leistung — kleinere Leistungsverbesserungen beim Laden und Rendern der Abdeckung.

Aktivierungsschlüssel werden jetzt automatisch ausgestellt und angewendet — kein Warten mehr auf eine E-Mail.

Geändert

• Automatisierte Aktivierung — die Anforderung eines Schlüssels sendet jetzt einen kurzen Fragebogen und wendet den erhaltenen Schlüssel automatisch auf Ihre Einstellungen an, ohne E-Mail-Austausch.
• Schnellere Verlängerungen — eine Verlängerungsanfrage fragt nur nach Nutzung und Wünschen; Ihre Kontaktdaten aus einer früheren Anfrage werden wiederverwendet, nie erneut abgefragt.
• Festes Evaluierungsfenster — die Testphase läuft jetzt für alle bis zum 31.12.2026, anstelle des bisherigen 14-Tage-Countdowns ab der Installation.
• Lokalisierter Aktivierungsablauf — der Erneuerungsfragebogen und die Aktivierungsbestätigungen sind jetzt in alle 18 unterstützten Sprachen übersetzt, genau wie der Rest der Erweiterung.

Die Erweiterung prüft jetzt sowohl fucini.software als auch den VS Code Marketplace auf Updates und bietet immer die jeweils neuere Version an.

Behoben

• Prüfung aus zwei Quellen — fragt jetzt sowohl fucini.software als auch den VS Code Marketplace ab und bietet die jeweils neuere Version an.

Erste öffentliche Version von Fucini Coverage Studio — native VS-Code-Coverage, die Tracedateien gängiger Industriestandards einliest, in ein kanonisches Modell normalisiert, Läufe deterministisch zusammenführt und über die integrierte Test-Coverage-API von VS Code berichtet.

Hinzugefügt

• Mehrformat-Einlesung — LCOV, llvm-cov JSON, Cobertura XML, JaCoCo XML, Istanbul/nyc und SimpleCov JSON, automatisch erkannt.
• Deterministisches Zusammenführen — mehrere Tracedateien werden mit erfasster Herkunft zu einem Lauf kombiniert, stabil unabhängig von der Ladereihenfolge.
• Native Coverage-UI — Zeilen-/Branch-/Funktions-Gutter, Übersichtslineal und das integrierte Test-Coverage-Panel.
• MC/DC-Coverage — Aufschlüsselung pro Entscheidung beim Hover und ein optionaler farbiger Rand-Gutter.
• Kombinierter Score — ein SIL-gewichtetes gewichtetes harmonisches Mittel über Zeilen, Branches, Funktionen, Regionen, MC/DC und C++-Instanziierungen.
• Compliance-Urteil — COMPLIANT-/NON-COMPLIANT-Gating mit den Modi strict, whm, both und either.
• Pfadumschreibung, Diff-Coverage, Explorer-Badges und eine projektweite Statusleiste.
• Analyse im Editor — Funktions-CodeLens, Branch-Hover, Warnungen für toten Code, Warnungen für veraltete Coverage sowie Next/Previous Uncovered.
• Ansicht abgedeckter Dateien, HTML-Berichte, Verlauf & Trends, Watch-Modus und Fucini-JSON-Export.