Coverage Studio w wierszu poleceń 2.2026.4 — plik zmierzony przez dwa silniki liczy się raz, skądkolwiek uruchomisz polecenie
2026-10-04
Naprawiono
- Katalog, z którego uruchamiasz polecenie, nie decyduje o tym, co znaczy raport. 2.2026.3 zakorzenia ścieżki względne raportu w katalogu, w którym ten raport zapisano — ale tylko dla polecenia uruchomionego gdzie indziej. Uruchomione z korzenia mierzonego drzewa, czyli stamtąd, skąd polecenie pokrycia uruchamia się zwykle, ścieżkę względną nadal rozstrzygał ten katalog, a plik, który llvm-cov nazwał już pełną ścieżką, liczono po raz drugi: drzewo o 5258 wierszach czytano jako 5836. Teraz decydują wyłącznie
--cwd i miejsce samego raportu. Ta sama poprawka jest w obu edytorach, gdzie tym katalogiem był ten, z którego uruchomiono VS Code albo Visual Studio. export --format json zapisywał przebieg na twoich ustawieniach. Jego plik nazywał się fucini-coverage.json — tak jak plik, z którego czytane są ustawienia — więc w zwyczajnie skonfigurowanym katalogu eksport niszczył progi, według których właśnie orzekał. Przebieg zapisywany jest do coverage-run.json, a export i badge odmawiają --out wskazującego plik ustawień. --cwd przyjmuje katalog, jakkolwiek go zapiszesz. Względny — --cwd ., --cwd ../tree — brano tak, jak go wpisano, i czytano według niewłaściwych reguł ścieżek: w systemie Windows odpowiadał, że pliku ustawień w połowie POSIX, w połowie Windows nie da się odczytać, i nie znajdował żadnych raportów. Końcowy separator również nie należy już do katalogu. - Flaga, której nikt nie zadeklarował, nie jest raportem.
summary -o out.json brał -o za raport i mówił, że takiego pliku nie ma. Krótkie są tylko -h i -v; -- nadal przekazuje plik, którego nazwa zaczyna się od myślnika, a flaga wpisana przed poleceniem jest nazwana w komunikacie o błędzie zamiast otrzymywać w odpowiedzi całą pomoc. check --json mówi to, co mówi jego kod wyjścia. Bez ustawionego progu pisał "passed": false obok kodu wyjścia 0, a potok, który czytał JSON zamiast kodu wyjścia, oblewał przebieg, który polecenie zaliczyło. passed to kod wyjścia w jednym słowie; configured mówi, że bramki w ogóle nie było. Puste --lines "" jest odrzucane, zamiast po cichu wyłączać tę bramkę. - Porównanie kładzie punkt odniesienia tam, gdzie kładzie przebieg.
pathRemap i korzeń deklarowany przez raport stosowano do przebiegu, a nie do punktu odniesienia, więc punkt odniesienia zapisany na serwerze kompilacji nie łączył się w pary z niczym i porównanie meldowało, że nic się nie zmieniło, obok sumy, która wyraźnie się zmieniła.
Coverage Studio w wierszu poleceń 2.2026.3 — plik zmierzony przez dwa silniki znów jest jednym plikiem
2026-10-04
Naprawiono
- Ścieżki względne raportu są zakorzenione tam, gdzie ten raport został zapisany. llvm-cov zapisuje pełną ścieżkę pliku; gcovr zapisuje ją względem katalogu kompilacji, w którym leży jego raport. Mając oba raporty jednego drzewa,
summary wypisywał dwukrotnie każdy plik, który oba miały wspólny — raz z liczbami każdego silnika — i dodawał oba do sumy, ponieważ ścieżka względna nie miała korzenia, względem którego mogłaby się rozwiązać, i rozwiązywała się względem katalogu, w którym akurat znajdowała się powłoka. Drzewo o 5258 wierszach raportowano jako 5836, a nadwyżka należała do plików pod ścieżką, która żadnego z nich nie zawiera. Każdy raport jest teraz zakorzeniony we własnym katalogu i w katalogach powyżej, aż do katalogu, w którym działa polecenie, tak jak robią to już obie edycje — dzięki temu oba spotykają się jako jeden zbiór plików, bez reguły pathRemap dla każdego katalogu kompilacji. - Plik ustawień zaczynający się od znacznika kolejności bajtów również był odrzucany. Edytor w systemie Windows może go zapisać przed tekstem; nie jest już brany za część JSON-a.
- Wyjście przekazane do czytnika, który kończy wcześnie, kończy się spokojnie.
summary przekazany do head albo do Select-Object -First w PowerShellu umierał z nieobsłużonym EPIPE i śladem stosu. Zamknięcie potoku przez czytnik to jego własna decyzja, a nie błąd polecenia: kończy się ono teraz z kodem wyjścia, który osiągnęło.
Coverage Studio w wierszu poleceń 2.2026.1 — plik ustawień z wzorcami jest odczytywany
2026-10-04
Naprawiono
- Plik ustawień z wzorcami był odrzucany. Gdy w jednej ścieżce
fuciniCoverage.coverageFile.paths stało **/*.lcov.info, a w następnej **/coverage.json, każde polecenie kończyło się komunikatem is not JSON: to, co znajdowało się między nimi, było brane za komentarz. Plik jest teraz odczytywany tak, jak czytają go edytory — łącznie z komentarzem po wartości i przecinkiem przed nawiasem zamykającym.
Coverage Studio w wierszu poleceń 2.2026.0 — fucini-coverage, pierwsze wydanie
2026-10-04
Dodano
- Czytnik w wierszu poleceń, za darmo.
npm install -g fucini-coverage — ten sam czytnik co w obu edycjach, dla miejsc, gdzie nie ma edytora. Jeden pakiet, jedno zachowanie w systemach Windows, Linux, WSL i macOS, Node 20 lub nowszy.
check, bramka. Kod wyjścia 1 poniżej progu dla wierszy, gałęzi, funkcji, MC/DC, warunków, regionów, mutacji lub wyniku ważonego, z ustawień albo z wiersza poleceń; --new-code 80 --base-ref origin/main ocenia wiersze zmienione przez gałąź, na podstawie git diff uruchamianego przez narzędzie; --require-reasons odrzuca znacznik wykluczenia bez powodu.
summary, export, report, badge, compare. Sumy i każdy plik; przebieg jako CSV na plik lub na funkcję, Markdown, LCOV, Cobertura, SARIF, lista wykluczeń, odznaka lub JSON Fucini; wielostronicowy raport HTML; odznaka pokolorowana według skali z ustawień; ten przebieg wobec linii bazowej, regresje najpierw, z --fail-on-regression do sprawdzenia pull requesta.
mcp, dla agenta AI. Sześć narzędzi z edycji, serwowanych nad przebiegiem na 127.0.0.1 za tokenem, z wydrukowanym wpisem do mcp.json klienta.
- Plik ustawień edycji dla Visual Studio.
fucini-coverage.json obok kodu, z kluczami fuciniCoverage.* z ustawień VS Code; pod nim .vscode/settings.json. Raporty wskazuje się jako pliki, foldery lub wzorce, .gz jest rozpakowywany, a każde polecenie dokumentuje się samo: fucini-coverage help <command>.
Coverage Studio for VS Code 2.2026.2 — okres próbny zaczyna się wraz z odpowiedzią serwera licencji
2026-10-04
Zmieniono
- Okres próbny nowej instalacji zaczyna się wraz z pierwszą odpowiedzią serwera licencji. Dopóki rozszerzenie raz nie połączy się z fucini.software, działa na poziomie Community i mówi dlaczego. Instalacja, która jest już w okresie próbnym albo ma licencję, niczego nie zauważy.
- Bez okresu próbnego w kontenerze deweloperskim lub Codespace. Tam rozszerzenie startuje na poziomie Community; wszystko odblokowuje kod subskrypcji, klucz lub 7-dniowa przepustka.
- Rejestr użycia zna maszynę po drugim skrócie, z własnego identyfikatora systemu operacyjnego. Wysyłany jest tylko skrót; zob. politykę prywatności.
Coverage Studio dla Visual Studio 2.2026.1 — drobne poprawki
2026-10-04
Naprawiono
- Drobne poprawki. Wydanie serwisowe: drobne poprawki pod maską i nic, co zmienia to, co widzisz, ani sposób użycia.
Coverage Studio for VS Code 2.2026.1 — drobne poprawki
2026-10-04
Naprawiono
- Drobne poprawki. Wydanie serwisowe: drobne poprawki pod maską i nic, co zmienia to, co widzisz, ani sposób użycia.
Coverage Studio dla Visual Studio 2.2026.0 — pokrycie z ekranu, dla agentów AI
2026-10-04
Dodano
- Pokrycie z ekranu, dla agentów AI. Agent piszący testy mógł je uruchomić i odczytać procent; nie mógł zapytać o to, co wie Visual Studio. Odpowiada na to sześć narzędzi, słowami, na podstawie których agent może działać:
coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta i test_run_command. Agent mówiący w MCP dociera do nich przez serwer, który Visual Studio uruchamia, gdy fuciniCoverage.mcp.enabled jest włączone — domyślnie wyłączone, tylko na 127.0.0.1, za twoim własnym tokenem i zamknięte dla stron internetowych. Copy MCP Server Configuration umieszcza wpis klienta w schowku. - Te same liczby co na ekranie. Narzędzia odpowiadają na podstawie wczytanego przebiegu — te same wykluczenia, to samo przemapowanie — więc agent, któremu kazano pokryć luki funkcji, i recenzent patrzący na margines mówią o tych samych wierszach.
Zmieniono
- Plan klucza rozstrzyga w Visual Studio o tym samym, o czym w VS Code. Plan, który pomija jakąś funkcję — MC/DC, raport HTML, nazwy testów, które wykonały wiersz — pomijał ją w VS Code, a tutaj nie. Obie edycje czytają teraz tę samą tabelę: funkcja, której plan nie obejmuje, jest niedostępna, a jej polecenie o tym mówi.
- Minimalna wersja, której wymaga serwer licencji, obowiązuje również tutaj. Od 2.2026.0 obie edycje mają tę samą wersję, więc kompilacja starsza niż to minimum prosi o aktualizację, tak jak edycja dla VS Code.
Coverage Studio for VS Code 2.2026.0 — pokrycie z ekranu, dla agentów AI
2026-10-04
Dodano
- Pokrycie z ekranu, dla agentów AI. Agent piszący testy mógł je uruchomić i odczytać procent; nie mógł zapytać o to, co wie edytor. Odpowiada na to sześć narzędzi, słowami, na podstawie których agent może działać:
coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta i test_run_command. Własny agent VS Code ma je jako narzędzia modelu językowego, bez żadnej konfiguracji. Każdy inny agent mówiący w MCP dociera do nich przez serwer, który rozszerzenie uruchamia, gdy fuciniCoverage.mcp.enabled jest włączone — domyślnie wyłączone, tylko na 127.0.0.1, za twoim własnym tokenem i zamknięte dla stron internetowych. Copy MCP Server Configuration umieszcza wpis klienta w schowku. - Te same liczby co na ekranie. Narzędzia odpowiadają na podstawie wczytanego przebiegu — te same wykluczenia, to samo przemapowanie — więc agent, któremu kazano pokryć luki funkcji, i recenzent patrzący na margines mówią o tych samych wierszach.
Coverage Studio dla Visual Studio 1.2026.22 — plik zmierzony przez dwa silniki jest jednym plikiem
2026-10-04
Naprawiono
- Plik zmierzony przez dwa silniki jest jednym plikiem. llvm-cov zapisuje pełną ścieżkę pliku; gcovr zapisuje ją względem katalogu kompilacji, w którym leży jego raport. Ścieżka względna jest zakorzeniana w katalogu samego raportu i katalogach nad nim — ale wcześniej mechanizm rozstrzygania pytał, czy ścieżka istnieje w takiej postaci, w jakiej stoi, a na to pytanie odpowiada katalog, z którego uruchomiono sam Visual Studio. Jeśli ten katalog zawierał plik, ścieżka pozostawała względna: plik miał dwie nazwy, pojawiał się dwukrotnie w oknie Coverage i był dwukrotnie liczony w sumach. Drzewo o 5258 wierszach czytano jako 5836. Ścieżka, która nie nazywa żadnego własnego miejsca, nie jest już w ogóle o to pytana; zakorzenia się tam, gdzie zapisano raport, a wiersz to mówi.
Coverage Studio dla VS Code 1.2026.23 — plik zmierzony przez dwa silniki jest jednym plikiem, a wybrany tryb marginesu nie trafia do twoich ustawień
2026-10-04
Naprawiono
- Plik zmierzony przez dwa silniki jest jednym plikiem. llvm-cov zapisuje pełną ścieżkę pliku; gcovr zapisuje ją względem katalogu kompilacji, w którym leży jego raport. Ścieżka względna jest zakorzeniana w katalogu samego raportu i katalogach nad nim — ale wcześniej mechanizm rozstrzygania pytał, czy ścieżka istnieje w takiej postaci, w jakiej stoi, a na to pytanie odpowiada katalog, z którego uruchomiono extension host, czyli po
code . korzeń twojego projektu. Ścieżka pozostawała wtedy względna: plik miał dwie nazwy, pojawiał się dwukrotnie w widoku Coverage i był dwukrotnie liczony w sumach. Drzewo o 5258 wierszach czytano jako 5836. Ścieżka, która nie nazywa żadnego własnego miejsca, nie jest już w ogóle o to pytana; zakorzenia się tam, gdzie zapisano raport, a wiersz to mówi. - Wybrany tryb marginesu obowiązuje przez sesję, a twoje ustawienia zostają takie, jak je napisałeś. Wybór trybu na pasku stanu, w selektorze lub przez Toggle Coverage Painting zapisywał go w
settings.json — pliku, który w wielu projektach jest pod kontrolą wersji, a przepisywał go przycisk pomyślany tak, by naciskać go dwa razy na minutę. Wybór żyje teraz przez sesję, a tryb wpisany przez ciebie do ustawień nadal wygrywa przy otwarciu okna.
Coverage Studio dla Visual Studio 1.2026.21 — czy test by to zauważył? Przebieg mutacji przy kursorze
2026-10-03
Dodano
- Run Mutation Tests Here. Pokrycie mówi, że wiersz został wykonany; narzędzie do mutacji mówi, czy test zauważyłby, że jest błędny. Funkcja, w której stoi kursor — albo zaznaczone wiersze, albo plik — jest tym, co narzędzie uruchamiające z folderu ma zmutować, a jego raport jest wczytywany obok pokrycia na ekranie: Stryker.NET dla C#, StrykerJS dla JavaScript i TypeScript, PIT z Maven dla Java. Przebieg mutacji całego projektu trwa godzinę; jednej funkcji — minutę.
Coverage Studio for VS Code 1.2026.22 — czy test by to zauważył? Przebieg mutacji przy kursorze
2026-10-03
Dodano
- Run Mutation Tests Here. Pokrycie mówi, że wiersz został wykonany; narzędzie do mutacji mówi, czy test zauważyłby, że jest błędny. Funkcja, w której stoi kursor — albo zaznaczone wiersze, albo plik — jest tym, co narzędzie uruchamiające z folderu ma zmutować, a jego raport jest wczytywany obok pokrycia na ekranie: Stryker.NET dla C#, StrykerJS dla JavaScript i TypeScript, PIT z Maven dla Java. Przebieg mutacji całego projektu trwa godzinę; jednej funkcji — minutę.
Coverage Studio dla Visual Studio 1.2026.20 — sama aplikacja, z pokryciem
2026-10-03
Dodano
- Run App with Coverage… mierzy to, do czego dociera człowiek, a nie tylko to, co robią testy: aplikacja .NET z folderu jest uruchamiana pod
dotnet-coverage firmy Microsoft, we własnej konsoli, i działa, dopóki nie zostanie zamknięta. To, przez co przeszedł człowiek, jest potem wczytywane jak każdy przebieg, a w sesji pokrycia dodawane do tego, co wykonały testy. Wymaga dotnet tool install --global dotnet-coverage.
Coverage Studio for VS Code 1.2026.21 — sama aplikacja, z pokryciem
2026-10-03
Dodano
- Run App with Coverage… mierzy to, do czego dociera człowiek, a nie tylko to, co robią testy: aplikacja .NET z folderu jest uruchamiana pod
dotnet-coverage firmy Microsoft, we własnej konsoli, i działa, dopóki nie zostanie zamknięta. To, przez co przeszedł człowiek, jest potem wczytywane jak każdy przebieg, a w sesji pokrycia dodawane do tego, co wykonały testy. Wymaga dotnet tool install --global dotnet-coverage.
Coverage Studio dla Visual Studio 1.2026.19 — artefakty zip z GitHub i GitLab
2026-10-03
Dodano
- Punkt odniesienia z CI z artefaktu zip. GitHub i GitLab publikują artefakt jako archiwum. Tam, gdzie
baseline.report wskazuje archiwum — adres URL albo zip na dysku — jest ono otwierane, a raport z niego zachowywany: element wskazany po # (ci/artifact.zip#coverage/lcov.info), w przeciwnym razie jedyny plik archiwum, a w przeciwnym razie jedyny jego plik, który wygląda na raport.
Coverage Studio for VS Code 1.2026.20 — artefakty zip z GitHub i GitLab
2026-10-03
Dodano
- Artefakty zip z GitHub i GitLab. CI publikuje artefakt, a artefakt to archiwum. Pobrany zip jest teraz otwierany, a raport z niego zachowywany — element wskazany po
# w adresie URL (…/zip#coverage/lcov.info), w przeciwnym razie jedyny plik archiwum, a w przeciwnym razie jedyny jego plik, który wygląda na raport. Dla adresu URL w coverageFile.paths, dla baseline.report i dla punktu odniesienia, który jest plikiem zip na dysku.
Naprawiono
- Pliki punktu odniesienia Cobertura nie były znajdowane pod własnym
<source> raportu. Porównanie mówiło 0 file(s) moved obok sumy, która się zmieniła. Teraz używany jest katalog główny wskazany przez raport, tak jak dla raportu, który jest wczytywany.
Coverage Studio dla Visual Studio 1.2026.18 — nowy kod według autora i daty
2026-10-03
Dodano
- Nowy kod według autora i daty. Nowym kodem były wiersze zmienione względem referencji git. Dwa ustawienia pytają o to, czego referencja nie potrafi:
fuciniCoverage.gitDiff.author — wiersze napisane przez jedną osobę — oraz fuciniCoverage.gitDiff.since — wiersze napisane od danego dnia. Oba są odczytywane z git blame i dotyczą pokrycia różnic oraz progu dla nowego kodu.
Coverage Studio for VS Code 1.2026.19 — nowy kod według autora i daty
2026-10-03
Dodano
- Nowy kod według autora i daty. Nowym kodem były wiersze zmienione względem referencji git. Dwa ustawienia pytają o to, czego referencja nie potrafi:
fuciniCoverage.gitDiff.author — wiersze napisane przez jedną osobę — oraz fuciniCoverage.gitDiff.since — wiersze napisane od danego dnia. Oba są odczytywane z git blame i dotyczą pokrycia różnic oraz progu dla nowego kodu.
Coverage Studio dla Visual Studio 1.2026.17 — jeden test z pokryciem, w Go i Rust
2026-10-02
Dodano
- Run This Test with Coverage czyta Go i Rust. W pliku Go
func TestXxx spod kursora uruchamia się samo, we własnym pakiecie i po dokładnej nazwie — go test ./pkg/calc -run "^TestTotal$". W pliku Rust funkcja #[test] uruchamia się po swojej ścieżce w crate, z --exact; w mod — testy tego modułu; test integracyjny pod tests/ — we własnym pliku binarnym.
Coverage Studio for VS Code 1.2026.18 — jeden test z pokryciem, w Go i Rust
2026-10-02
Dodano
- Run This Test with Coverage czyta Go i Rust. W pliku Go
func TestXxx spod kursora uruchamia się samo, we własnym pakiecie i po dokładnej nazwie — go test ./pkg/calc -run "^TestTotal$". W pliku Rust funkcja #[test] uruchamia się po swojej ścieżce w crate, z --exact; w mod — testy tego modułu; test integracyjny pod tests/ — we własnym pliku binarnym.
Coverage Studio dla Visual Studio 1.2026.16 — pokrycie warunków z GCC 14, wiersz po wierszu
2026-10-02
Dodano
- Pokrycie warunków z GCC 14, wiersz po wierszu.
-fcondition-coverage było czytane jako dwa liczniki na plik; teraz każdy warunek jest oznaczany w swoim wierszu i nazywany w dymku — warunek 1 nigdy prawdziwy, warunek 0 nigdy w żadną stronę — z JSON-a gcov i z jego listingu tekstowego. threshold.conditions nakłada na nie próg, Copy Coverage Summary ma kolumnę Conditions, badge.metric przyjmuje conditions, a wyszukiwanie przyjmuje conditions < 80.
Naprawiono
- Liczba gałęzi funkcji obejmowała też wyniki jej warunków.
branches 8/12 tam, gdzie narzędzie mówiło 4 z 6. Warunki są tam pomijane, tak jak w liczbach pliku i przebiegu.
Coverage Studio for VS Code 1.2026.17 — pokrycie warunków z GCC 14, wiersz po wierszu
2026-10-02
Dodano
- Pokrycie warunków z GCC 14, wiersz po wierszu.
-fcondition-coverage było czytane jako dwa liczniki na plik; teraz każdy warunek jest oznaczany w swoim wierszu i nazywany w dymku — warunek 1 nigdy prawdziwy, warunek 0 nigdy w żadną stronę — z JSON-a gcov i z jego listingu tekstowego. threshold.conditions nakłada na nie próg, Copy Coverage Summary ma kolumnę Conditions, badge.metric przyjmuje conditions, a wyszukiwanie przyjmuje conditions < 80.
Naprawiono
- Liczba gałęzi funkcji obejmowała też wyniki jej warunków.
branches 8/12 tam, gdzie narzędzie mówiło 4 z 6. Warunki są tam pomijane, tak jak w liczbach pliku i przebiegu.
Coverage Studio dla Visual Studio 1.2026.15 — widok Coverage podąża za edytorem
2026-10-02
Dodano
- Widok Coverage podąża za edytorem. Plik, na który patrzysz, jest podświetlany w drzewie, foldery nad nim są rozwijane, a jego wiersz jest przewijany tak, by był widoczny.
fuciniCoverage.coverageView.followActiveEditor to wyłącza.
Coverage Studio for VS Code 1.2026.16 — widok Coverage podąża za edytorem
2026-10-02
Dodano
- Widok Coverage podąża za edytorem. Plik, na który patrzysz, jest podświetlany w drzewie, foldery nad nim są rozwijane, a jego wiersz jest przewijany tak, by był widoczny.
fuciniCoverage.coverageView.followActiveEditor to wyłącza.
Coverage Studio dla Visual Studio 1.2026.14 — znaczniki wykluczające tylko gałęzie i pokrycie gałęzi w raportach .NET
2026-10-02
Dodano
- Znaczniki wykluczające tylko gałęzie oraz znaczniki gcovr.
LCOV_EXCL_BR_LINE oraz LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP wyjmują z liczenia gałęzie w swoich wierszach, a same wiersze w nim zostawiają; LCOV_EXCL_EXCEPTION_BR_LINE wyjmuje tylko odnogi, do których dociera wyjątek. Każdy znacznik jest czytany również z prefiksami gcovr: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE i pozostałe.
Naprawiono
- Raport .NET nie pokazywał pokrycia gałęzi. Coverlet i
dotnet-coverage zapisują atrybut branch wiersza Cobertura jako True, a czytane było tylko true małymi literami — więc każda decyzja w takim raporcie przepadała. Teraz czytane są obie pisownie. Liczby się zmieniają: pokrycie gałęzi projektu .NET pojawia się tam, gdzie go nie było, a wraz z nim jego wynik. - Raport Cobertura scalony z kilku drzew znajdował tylko pliki pierwszego drzewa. Taki raport podaje po jednym
<source> na drzewo; teraz próbowany jest każdy, w kolejności z raportu.
Coverage Studio for VS Code 1.2026.15 — znaczniki wykluczające tylko gałęzie i pokrycie gałęzi w raportach .NET
2026-10-02
Dodano
- Znaczniki wykluczające tylko gałęzie oraz znaczniki gcovr.
LCOV_EXCL_BR_LINE oraz LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP wyjmują z liczenia gałęzie w swoich wierszach, a same wiersze w nim zostawiają; LCOV_EXCL_EXCEPTION_BR_LINE wyjmuje tylko odnogi, do których dociera wyjątek. Każdy znacznik jest czytany również z prefiksami gcovr: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE i pozostałe.
Naprawiono
- Raport .NET nie pokazywał pokrycia gałęzi. Coverlet i
dotnet-coverage zapisują atrybut branch wiersza Cobertura jako True, a czytane było tylko true małymi literami — więc każda decyzja w takim raporcie przepadała. Teraz czytane są obie pisownie. Liczby się zmieniają: pokrycie gałęzi projektu .NET pojawia się tam, gdzie go nie było, a wraz z nim jego wynik. - Raport Cobertura scalony z kilku drzew znajdował tylko pliki pierwszego drzewa. Taki raport podaje po jednym
<source> na drzewo; teraz próbowany jest każdy, w kolejności z raportu.
Coverage Studio dla Visual Studio 1.2026.13 — najmniej testów, które wciąż wykonują każdy wiersz
2026-10-01
Dodano
- Show Minimal Test Set… znajduje najmniejszą liczbę testów, które wciąż wykonują każdy wiersz wykonywany przez cały zestaw, a pod nimi wymienia testy, które nie dodają żadnego własnego wiersza. Do szybkiego przebiegu przed commitem i dla tego, kto przycina zestaw — z przypomnieniem, że zbędny pod względem wierszy nie znaczy zbędny pod względem tego, co test sprawdza.
Coverage Studio for VS Code 1.2026.14 — najmniej testów, które wciąż wykonują każdy wiersz
2026-10-01
Dodano
- Show Minimal Test Set… znajduje najmniejszą liczbę testów, które wciąż wykonują każdy wiersz wykonywany przez cały zestaw, a pod nimi wymienia testy, które nie dodają żadnego własnego wiersza. Do szybkiego przebiegu przed commitem i dla tego, kto przycina zestaw — z przypomnieniem, że zbędny pod względem wierszy nie znaczy zbędny pod względem tego, co test sprawdza.
Coverage Studio dla Visual Studio 1.2026.12 — wykluczenia, które mówią dlaczego
2026-10-01
Dodano
- Uzasadnione wykluczenia. Kod wyjęty z liczenia tam, gdzie jest napisany, może powiedzieć dlaczego —
// LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] — a powody trafiają do raportu: Export Coverage Report… wymienia wykluczenia i ich uzasadnienia jako Markdown i jako CSV. Z fuciniCoverage.exclusions.requireReason wykluczenie bez podanego powodu jest ostrzeżeniem w swoim wierszu i sprawia, że Check Coverage Thresholds kończy się niepowodzeniem.
Coverage Studio for VS Code 1.2026.13 — wykluczenia, które mówią dlaczego
2026-10-01
Dodano
- Uzasadnione wykluczenia. Kod wyjęty z liczenia tam, gdzie jest napisany, może powiedzieć dlaczego —
// LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] — a powody trafiają do raportu: Export Coverage Report… wymienia wykluczenia i ich uzasadnienia jako Markdown i jako CSV. Z fuciniCoverage.exclusions.requireReason wykluczenie bez podanego powodu jest ostrzeżeniem w swoim wierszu i sprawia, że Check Coverage Thresholds kończy się niepowodzeniem.
Coverage Studio dla Visual Studio 1.2026.11 — próg dla nowego kodu i pokrycie, które zmieniło się bez edycji
2026-10-01
Dodano
- Próg dla nowego kodu, obok progów dla całego przebiegu.
fuciniCoverage.threshold.newCode to najmniejsze pokrycie wierszy, w procentach, dla wierszy zmienionych względem gitDiff.baseRef. Check Coverage Thresholds zgłasza jego niespełnienie osobnym zdaniem — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) — a cały przebieg zostaje na ekranie. - Show Indirect Coverage Changes… wymienia wiersze, których pokrycie się zmieniło, choć nikt ich nie edytował — kod, który przestał się wykonywać, bo zniknął test albo bo gałąź wyżej w kodzie teraz wcześniej zwraca. Względem punktu odniesienia z CI tam, gdzie
baseline.report go wskazuje, w przeciwnym razie względem poprzedniego przebiegu.
Coverage Studio for VS Code 1.2026.12 — próg dla nowego kodu i pokrycie, które zmieniło się bez edycji
2026-10-01
Dodano
- Próg dla nowego kodu, obok progów dla całego przebiegu.
fuciniCoverage.threshold.newCode to najmniejsze pokrycie wierszy, w procentach, dla wierszy zmienionych względem gitDiff.baseRef. Check Coverage Thresholds zgłasza jego niespełnienie osobnym zdaniem — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) — a cały przebieg zostaje na ekranie. - Show Indirect Coverage Changes… wymienia wiersze, których pokrycie się zmieniło, choć nikt ich nie edytował — kod, który przestał się wykonywać, bo zniknął test albo bo gałąź wyżej w kodzie teraz wcześniej zwraca. Względem punktu odniesienia z CI tam, gdzie
baseline.report go wskazuje, w przeciwnym razie względem poprzedniego przebiegu.
Coverage Studio dla Visual Studio 1.2026.10 — uruchom tylko testy, których dotyczą twoje zmiany
2026-10-01
Dodano
- Run Tests Affected by My Changes… wymienia testy, które wykonały wiersz zmieniony w drzewie roboczym względem
fuciniCoverage.testImpact.baseRef (domyślnie HEAD), zaczynając od tego, który wykonał największą część zmiany. Wybranie testu otwiera go; tam, gdzie raporty pochodzą z przebiegu dla pojedynczych testów (testRun.perTest), pierwsza pozycja uruchamia tylko te testy.
Naprawiono
testRun.skipWhenTestsFail obowiązuje także po przebiegu. Raporty zapisane przez czerwony przebieg zostawały na dysku, skąd obserwator wczytywał je chwilę później. Teraz są usuwane.- Kopia raportu pokrycia, którą robi logger TRX, nigdy nie jest brana za plik śladu.
Coverage Studio for VS Code 1.2026.11 — uruchom tylko testy, których dotyczą twoje zmiany
2026-10-01
Dodano
- Run Tests Affected by My Changes… wymienia testy, które wykonały wiersz zmieniony w drzewie roboczym względem
fuciniCoverage.testImpact.baseRef (domyślnie HEAD), zaczynając od tego, który wykonał największą część zmiany. Wybranie testu otwiera go; tam, gdzie raporty pochodzą z przebiegu dla pojedynczych testów (testRun.perTest), pierwsza pozycja uruchamia tylko te testy.
Naprawiono
testRun.skipWhenTestsFail obowiązuje także po przebiegu. Raporty zapisane przez czerwony przebieg zostawały na dysku, skąd obserwator wczytywał je chwilę później. Teraz są usuwane.- Kopia raportu pokrycia, którą robi logger TRX, nigdy nie jest brana za plik śladu.
Coverage Studio dla Visual Studio 1.2026.9 — zaliczone lub nie, wprost na oznaczeniach, oraz własne pliki pokrycia kodu Visual Studio
2026-09-30
Dodano
- Zaliczone lub nie, wprost na oznaczeniach. Wiersz wykonany przez niezaliczony test dostaje czerwony pasek na początku, a jego dymek wymienia niezaliczone testy; Show Tests That Ran This Line mówi, które z testów nie przeszły. Potrzebny jest raport, który mówi, które testy wykonały wiersz, oraz plik wyników narzędzia uruchamiającego testy — TRX lub JUnit XML — w folderze raportu albo wskazany w
fuciniCoverage.testResults.paths. Run Tests with Coverage prosi teraz dotnet test o taki plik. - Własne pokrycie kodu Visual Studio, wczytane. Plik
.coverage, który zapisuje Analyze Code Coverage w Visual Studio, jest konwertowany za pomocą dotnet-coverage i wczytuje się sam: Coverage Studio opiera się na wbudowanym kolektorze, zamiast z nim konkurować.
Coverage Studio for VS Code 1.2026.10 — zaliczone lub nie, wprost na oznaczeniach
2026-09-30
Dodano
- Zaliczone lub nie, wprost na oznaczeniach. Wiersz wykonany przez niezaliczony test dostaje czerwony pasek na początku, a jego dymek wymienia niezaliczone testy; Show Tests That Ran This Line mówi, które z testów nie przeszły. Potrzebny jest raport, który mówi, które testy wykonały wiersz, oraz plik wyników narzędzia uruchamiającego testy — TRX lub JUnit XML — w folderze raportu albo wskazany w
fuciniCoverage.testResults.paths. Run Tests with Coverage prosi teraz dotnet test o taki plik.
Coverage Studio dla Visual Studio 1.2026.8 — ponowne wczytania, które zachowują wyszukiwanie, sesję i ostatni przebieg
2026-09-30
Naprawiono
- Pole wyszukiwania zachowuje zapytanie i fokus, gdy pokrycie wczytuje się ponownie. Każde ponowne wczytanie je opróżniało, często gdy zapytanie było jeszcze wpisywane. Zapytanie takie jak
< 80% zachowuje też pasujące do niego punkty ryzyka. - Sesja pokrycia nie liczy już tego samego przebiegu dwa razy. Każde ponowne wczytanie niezmienionych raportów dodawało je jeszcze raz i każdy licznik wykonań się podwajał. Sesja przechowuje teraz każdy zestaw raportów jeden raz.
- Punkt odniesienia z CI nie wstrzymuje już wczytywania. Najpierw rysowane jest wczytanie, a porównanie przychodzi po nim. Punkt odniesienia jest przygotowywany raz i przechowywany, dopóki jego raport i ustawienia się nie zmienią, a gdy adres URL jest nieosiągalny, używana jest kopia pobrana wcześniej.
- „Od ostatniego przebiegu” przetrwa ponowne wczytanie niezmienionych raportów. Zmiana ustawień lub odświeżenie czyniły przebieg na ekranie jego własnym ostatnim przebiegiem i każda zmiana od przebiegu wcześniejszego znikała. Takie ponowne odczytanie nie jest też już zapisywane w historii.
- Jedno wczytanie naraz. Dwa ponowne wczytania zażądane jednocześnie biegły obok siebie i wygrywało wolniejsze. Ponowne wczytania zażądane w trakcie wczytywania stają się teraz jednym wczytaniem po nim.
- Punkt odniesienia z CI przez HTTP jest pobierany tak jak w VS Code. Jeden klient, ostatnia kopia zachowana na wypadek, gdy serwer jest nieosiągalny, a
remote.headers wysyłane tylko pod adres, dla którego je zapisano — nigdy zwykłym HTTP. - Polecenie, którego praca się nie powiedzie, mówi o tym. Błąd w poleceniu lub w czasomierzu był połykany; teraz jest wierszem w oknie Dane wyjściowe.
- Mniej pracy w wątku interfejsu użytkownika. Obserwatory plików są tworzone w tle, wpisy Listy błędów są wyliczane raz na wczytanie, a dziennik jest zapisywany porcjami zamiast wiersz po wierszu.
- Dwa okna Visual Studio nie uszkadzają już historii przebiegów. Jej indeks jest podmieniany w jednym kroku pod blokadą wspólną dla obu, a gdy zginie, jest odtwarzany z przebiegów.
- Run Native Project with Coverage buduje własną platformę projektu, a
llvm-cov i llvm-profdata bierze z LLVM kompilatora, jako parę. - Kolory ostrzeżenia, błędu i zaliczenia w oknie Coverage dostosowują się do jasnego motywu tak samo jak do ciemnego.
- Plik ustawień otwarty z niezapisanymi zmianami nie jest nadpisywany. Strona ustawień mówi, żeby najpierw go zapisać.
Zmieniono
- Wybrany przez ciebie plik pokrycia i raport zapisywany przez przebieg testów są zapamiętywane za ciebie, zamiast trafiać do
.vscode/settings.json. Ten plik często jest commitowany, więc przebieg testów zostawiał w repozytorium zmianę, o którą nikt nie prosił. Ścieżki, które już są w coverageFile.paths, działają dalej.
Coverage Studio for VS Code 1.2026.9 — ponowne wczytania, które zachowują wyszukiwanie, sesję i ostatni przebieg
2026-09-30
Naprawiono
- Pole wyszukiwania zachowuje zapytanie i fokus, gdy pokrycie wczytuje się ponownie. Każde ponowne wczytanie je opróżniało, często gdy zapytanie było jeszcze wpisywane. Zapytanie takie jak
< 80% zachowuje też pasujące do niego punkty ryzyka. - Sesja pokrycia nie liczy już tego samego przebiegu dwa razy. Każde ponowne wczytanie niezmienionych raportów dodawało je jeszcze raz i każdy licznik wykonań się podwajał. Sesja przechowuje teraz każdy zestaw raportów jeden raz.
- Punkt odniesienia z CI nie wstrzymuje już wczytywania. Najpierw rysowane jest wczytanie, a porównanie przychodzi po nim. Punkt odniesienia jest przygotowywany raz i przechowywany, dopóki jego raport i ustawienia się nie zmienią, a gdy adres URL jest nieosiągalny, używana jest kopia pobrana wcześniej.
- Sprawdzanie zmienionych plików raportów wykonuje jedno przejście naraz. Na wolnym dysku sieciowym dwa przejścia widziały tę samą zmianę i pokrycie wczytywało się dwa razy.
- „Od ostatniego przebiegu” przetrwa ponowne wczytanie niezmienionych raportów. Zmiana ustawień lub odświeżenie czyniły przebieg na ekranie jego własnym ostatnim przebiegiem i każda zmiana od przebiegu wcześniejszego znikała. Takie ponowne odczytanie nie jest też już zapisywane w historii.
Zmieniono
- Wybrany przez ciebie plik pokrycia i raport zapisywany przez przebieg testów są zapamiętywane za ciebie, zamiast trafiać do
.vscode/settings.json. Ten plik często jest commitowany, więc przebieg testów zostawiał w repozytorium zmianę, o którą nikt nie prosił. Ścieżki, które już są w coverageFile.paths, działają dalej.
Coverage Studio dla Visual Studio 1.2026.7 — przebiegi testów, które uruchamiają dokładnie to, co nazywają
2026-09-30
Naprawiono
- Rozwiązanie .NET z dwoma lub więcej projektami testowymi nie traci już pokrycia wszystkich projektów poza jednym.
dotnet test zapisywał po jednym raporcie na projekt i wszystkie były przenoszone do tego samego coverage/coverage.cobertura.xml, więc wczytywany był tylko ostatni. Taki folder uruchamia teraz dotnet test raz na projekt testowy, każdy raport trafia do coverage/<Project>/, a przebieg jednego projektu zastępuje tylko raport tego projektu. - Zapisanie kilku plików naraz uruchamia testy każdego zapisanego pliku. Z
testRun.onSave uruchamiały się tylko testy ostatniego pliku; zapisy, które nadejdą w trakcie przebiegu, są zachowywane i uruchamiane razem po nim. - Run This Test with Coverage i przebiegi dla pojedynczych testów uruchamiają dokładnie to, co nazywają. Filtr .NET dopasowywał po podciągu:
Total uruchamiał też TotalTax. Test jest teraz uruchamiany po dokładnej nazwie, klasa po nazwie z kropką na końcu, a test w klasie zagnieżdżonej jest znajdowany (Outer+Inner). - Test w jest albo vitest, którego tytuł zawiera
(, + lub $, uruchamia się. Tytuł trafiał do -t, które czyta wyrażenie regularne, więc taki test nie pasował do niczego i nic się nie uruchamiało. - Run This Test with Coverage czyta pliki testów VB i F#.
<Fact> nad Public Sub oraz [<Fact>] nad let lub member nigdy nie były rozpoznawane. - Anulowanie przebiegu testów kończy każdy proces, który ten przebieg uruchomił. Kończona była tylko powłoka, a
dotnet test działał za nią dalej. Zamknięcie Visual Studio również anuluje przebieg. - Pisanie w trakcie przebiegu po zapisie nie przesuwa już oznaczeń. Są przypięte do tekstu, który przebieg zmierzył.
- Rozwiązanie na udziale sieciowym uruchamia swoje testy właśnie tam. Przebieg startował w
C:\Windows, bo powłoka poleceń nie przyjmuje ścieżki \\server\share jako swojego folderu.
Coverage Studio for VS Code 1.2026.8 — przebiegi testów, które uruchamiają dokładnie to, co nazywają
2026-09-30
Naprawiono
- Rozwiązanie .NET z dwoma lub więcej projektami testowymi nie traci już pokrycia wszystkich projektów poza jednym.
dotnet test zapisywał po jednym raporcie na projekt i wszystkie były przenoszone do tego samego coverage/coverage.cobertura.xml, więc wczytywany był tylko ostatni. Taki folder uruchamia teraz dotnet test raz na projekt testowy, każdy raport trafia do coverage/<Project>/, a przebieg jednego projektu zastępuje tylko raport tego projektu. - Zapisanie kilku plików naraz uruchamia testy każdego zapisanego pliku. Z
testRun.onSave uruchamiały się tylko testy ostatniego pliku; zapisy, które nadejdą w trakcie przebiegu, są zachowywane i uruchamiane razem po nim. - Run This Test with Coverage i przebiegi dla pojedynczych testów uruchamiają dokładnie to, co nazywają. Filtr .NET dopasowywał po podciągu:
Total uruchamiał też TotalTax. Test jest teraz uruchamiany po dokładnej nazwie, klasa po nazwie z kropką na końcu, a test w klasie zagnieżdżonej jest znajdowany (Outer+Inner). - Test w jest albo vitest, którego tytuł zawiera
(, + lub $, uruchamia się. Tytuł trafiał do -t, które czyta wyrażenie regularne, więc taki test nie pasował do niczego i nic się nie uruchamiało. - Tytuł testu z cudzysłowami dociera do terminala w całości. Polecenie z
\" wewnątrz cudzysłowów rozpadało się na pierwszym z nich. - Run This Test with Coverage czyta pliki testów VB i F#.
<Fact> nad Public Sub oraz [<Fact>] nad let lub member nigdy nie były rozpoznawane. - Zadanie testowe, które kończy się bez uruchomienia procesu, nie zostawia już Run Tests with Coverage w wiecznym oczekiwaniu. Kończy się i mówi, że przebieg niczego nie zapisał.
Coverage Studio dla Visual Studio 1.2026.6 — które testy wykonały wiersz, pokrycie po każdym zapisie i punkt odniesienia z CI
2026-09-29
Dodano
- Które testy wykonały ten wiersz. Tam, gdzie raport to zapisuje — coverage.py z
--show-contexts, śledzone metody OpenCover, plik śladu lcov zapisany dla każdego testu — CodeLens funkcji mówi, ile testów ją wykonało, a Show Tests That Ran This Line wymienia je, najaktywniejsze najpierw, i otwiera wybrany. Dla przebiegu dotnet test ustawienie testRun.perTest uruchamia testy klasa po klasie, więc każdy raport mówi, która klasa go zapisała.
- Pokrycie po każdym zapisie. Z
testRun.onSave zapisanie pliku źródłowego uruchamia testy, które go pokrywają, z pokryciem, a margines za tym podąża. W rozwiązaniu .NET uruchamiane są tylko projekty testowe odwołujące się do projektu zapisanego pliku; kilka zapisów z rzędu to jeden przebieg.
- Run This Test with Coverage. Z kursorem w metodzie testowej, klasie testowej lub
describe albo w pliku testowym jedno polecenie uruchamia z pokryciem właśnie to — dotnet test --filter, jest/vitest -t lub identyfikator węzła pytest — i wczytuje to, co zapisało. Test jest odczytywany z tekstu, więc działa dla C#, VB, F#, JavaScript, TypeScript i Python bez usługi językowej.
- Exclude from Coverage i dwa filtry .NET. Kliknięcie prawym przyciskiem wiersza drzewa pokrycia lub Exclude This File from Coverage na otwartym pliku dodaje plik albo folder do
fuciniCoverage.ignore, a ten znika ze wszystkich sum. ignore.namespaces pomija pliki przestrzeni nazw (*.Migrations), a ignore.attributes klasę, metodę lub właściwość pod atrybutem — domyślnie ExcludeFromCodeCoverage, którego OpenCover, dotCover i przekonwertowany lcov nie respektują.
- Exclude Selection from Coverage. Zaznacz wiersze i wybierz akcję z żarówki lub menu kontekstowego edytora: nad klasą, metodą lub właściwością .NET zapisuje
[ExcludeFromCodeCoverage] — w krótkiej formie, gdy plik już importuje System.Diagnostics.CodeAnalysis — a gdzie indziej LCOV_EXCL_LINE lub parę LCOV_EXCL_START/STOP w komentarzu danego języka. Istniejący znacznik nie jest dublowany.
- Przestrzenie nazw, klasy i metody. Dla raportu .NET, który nazywa swoje klasy — Cobertura, Coverlet, OpenCover — lista Folders / Namespaces pokazuje ten sam przebieg według przestrzeni nazw, klasy i metody, z tym samym sortowaniem i filtrem; wiersz metody otwiera plik na tej metodzie. Typy generowane przez kompilator, takie jak
<>c i maszyny stanów async, są wliczane do klasy, dla której je wygenerowano.
- Pole wyszukiwania nad drzewem pokrycia. Wpisz słowa, aby zostawić wiersze, których nazwa lub ścieżka zawiera je wszystkie, albo porównanie —
< 80%, lines >= 90, branches = 0 — aby zostawić wiersze, których liczba je spełnia; oba naraz wymagają obu. Przeszukiwane są też wiersze metod i punkty ryzyka; Escape czyści.
- Run Native Project with Coverage. Projekt startowy C++, z menu Tools: projekt ClangCL jest budowany ponownie z instrumentacją pokrycia clang do
coverage/native/, uruchamiany, a jego raport wczytywany; każdy inny zestaw narzędzi działa pod OpenCppCoverage, jeśli jest zainstalowany, a gdy nie da się ani tak, ani tak, zdanie mówi, co zainstalować.
- Sesje pokrycia i trend. Start Coverage Session — i każdy przebieg wczytany od tej chwili jest dodawany do poprzednich — wiersze, gałęzie i funkcje tak samo: to, co wykonał którykolwiek z nich, jest pokryte — więc testy jednostkowe, integracyjne i przejście przez aplikację pokazują, co razem osiągnęły. Pod paskiem narzędzi pokrycie wierszy z zapisanej historii jest rysowane jako trend, jeden punkt na przebieg.
- Compare Two History Runs, jak w VS Code: wybierz dwa zachowane przebiegi, a pliki, które się między nimi zmieniły, zostaną wymienione od starszego do nowszego, niezależnie od kolejności wyboru.
- Compare with CI Baseline.
baseline.report wskazuje raport publikowany przez build gałęzi głównej — adres URL, pobierany z remote.headers, lub pobrany plik — i każde wczytanie jest z nim porównywane: karta paska stanu mówi, gdzie jest ten przebieg, a Compare with CI Baseline wymienia pliki, które się zmieniły. Punkt odniesienia przechodzi przez tę samą listę wykluczeń co przebieg, więc sumy porównują to samo z tym samym.
- Gdzie je znaleźć. Nowe polecenia są w Tools > Coverage Studio i w menu kontekstowym edytora; Show Tests That Ran This Line to także Ctrl+Shift+U, T, a Exclude Selection from Coverage to akcja żarówki.
Naprawiono
- Raport przebiegu testów nie zawiera już nazwy użytkownika i komputera. Kolektor Code Coverage firmy Microsoft nazywa swój raport
<user>_<machine>_<stamp>.cobertura.xml, a ta nazwa widniała w drzewie i na każdym jego zrzucie ekranu; raport jest teraz przed wczytaniem przemianowywany na coverage.cobertura.xml.
- O wygenerowanym pliku mówiono, że pominął go
fuciniCoverage.ignore. Każdy pominięty plik jest teraz liczony pod ustawieniem, które go pominęło — ignore, ignore.generated lub ignore.namespaces — więc pokazana nazwa to ta, którą trzeba zmienić.
- Plik śladu lcov zapisany dla każdego testu jest czytany jako jeden rekord na plik, z zsumowanymi sekcjami testów, tak jak czyta go VS Code; wcześniej rekord każdego testu był osobnym plikiem.
- Dziennik mówi, co parser pominął. Pliki, w których parser nie znalazł nic do instrumentacji (
FUCINI_PARSE_030), oraz własny opis luk raportu (FUCINI_PARSE_031, MissingPdb z OpenCover) są zapisywane w dzienniku, tak jak zapisuje je VS Code.
- Nagłówek z makrami nie stoi już w drzewie na 100%. llvm-cov i gcov przypisują użycia makra wierszom, które je definiują; gałęzie i funkcje na wykluczonych wierszach odchodzą teraz razem z wierszami, a plik bez niczego mierzalnego jest usuwany z przebiegu i wymieniany w wyjściu (
FUCINI_EXCLUDE_001).
- Pięć raportów odrzucanych jako nieobsługiwany format jest rozpoznawanych. JaCoCo XML z Kovera, raport Stryker.NET, raport NCover, stary resultset SimpleCov i raport SonarQube z wieloma pustymi plikami są teraz rozpoznawane po tym, co mają na początku. Raport Clover lub SonarQube, którego ścieżki zawierają słowo
cobertura, nie jest już czytany jako Cobertura.
- Liczby zgodne z narzędziami, które je zapisały. Wynik gałęzi buildu MC/DC zgadza się z
llvm-cov report; gałęzie wyjątków LCOV 2 (BRDA:12,e0,1,3) są liczone; funkcja llvm-cov jest deklarowana tylko w pliku, który ją definiuje; blok Go wymieniony przez dwa pliki binarne testów sumuje swoje liczniki; decyzja Cobertura zgłaszana przez dwie klasy i wiersz JaCoCo wymieniony dwa razy zachowują wszystkie swoje gałęzie, raz.
- Drobniejsze. Plik śladu przerwany w trakcie zapisu nie gubi już pliku;
gcov -t na kilku plikach .gcda daje po pliku na każdy, instancje szablonów są czytane raz, a liczniki takie jak 1.20k z gcov -H są zachowywane; pliki GNATcoverage nie są już wszystkie zgłaszane jako zmienione od czasu pokrycia; oczekujący mutant Stryker ani przerwany przebieg PIT nie obniżają już wyniku.
- Ręczna zmiana pliku ustawień jest stosowana po jego zapisaniu, tak jak VS Code stosuje zmianę ustawień.
Coverage Studio for VS Code 1.2026.7 — które testy wykonały wiersz, pokrycie po każdym zapisie i punkt odniesienia z CI
2026-09-29
Dodano
- Które testy wykonały ten wiersz. Tam, gdzie raport to zapisuje — coverage.py z
--show-contexts, śledzone metody OpenCover, plik śladu lcov zapisany dla każdego testu — CodeLens funkcji mówi, ile testów ją wykonało, a Show Tests That Ran This Line wymienia je, najaktywniejsze najpierw, i otwiera wybrany. Dla przebiegu dotnet test ustawienie testRun.perTest uruchamia testy klasa po klasie, więc każdy raport mówi, która klasa go zapisała.
- Pokrycie po każdym zapisie. Z
testRun.onSave zapisanie pliku źródłowego uruchamia testy, które go pokrywają, z pokryciem, a margines za tym podąża. W rozwiązaniu .NET uruchamiane są tylko projekty testowe odwołujące się do projektu zapisanego pliku; kilka zapisów z rzędu to jeden przebieg.
- Run This Test with Coverage. Z kursorem w metodzie testowej, klasie testowej lub
describe albo w pliku testowym jedno polecenie uruchamia z pokryciem właśnie to — dotnet test --filter, jest/vitest -t lub identyfikator węzła pytest — i wczytuje to, co zapisało. Test jest odczytywany z tekstu, więc działa dla C#, VB, F#, JavaScript, TypeScript i Python bez usługi językowej.
- Exclude from Coverage i dwa filtry .NET. Kliknięcie prawym przyciskiem wiersza drzewa pokrycia lub Exclude This File from Coverage na otwartym pliku dodaje plik albo folder do
fuciniCoverage.ignore, a ten znika ze wszystkich sum. ignore.namespaces pomija pliki przestrzeni nazw (*.Migrations), a ignore.attributes klasę, metodę lub właściwość pod atrybutem — domyślnie ExcludeFromCodeCoverage, którego OpenCover, dotCover i przekonwertowany lcov nie respektują.
- Exclude Selection from Coverage. Zaznacz wiersze i wybierz akcję z żarówki lub menu kontekstowego edytora: nad klasą, metodą lub właściwością .NET zapisuje
[ExcludeFromCodeCoverage] — w krótkiej formie, gdy plik już importuje System.Diagnostics.CodeAnalysis — a gdzie indziej LCOV_EXCL_LINE lub parę LCOV_EXCL_START/STOP w komentarzu danego języka. Istniejący znacznik nie jest dublowany.
- Przestrzenie nazw, klasy i metody. Dla raportu .NET, który nazywa swoje klasy — Cobertura, Coverlet, OpenCover — lista Folders / Namespaces pokazuje ten sam przebieg według przestrzeni nazw, klasy i metody, z tym samym sortowaniem i filtrem; wiersz metody otwiera plik na tej metodzie. Typy generowane przez kompilator, takie jak
<>c i maszyny stanów async, są wliczane do klasy, dla której je wygenerowano.
- Pole wyszukiwania nad drzewem pokrycia. Wpisz słowa, aby zostawić wiersze, których nazwa lub ścieżka zawiera je wszystkie, albo porównanie —
< 80%, lines >= 90, branches = 0 — aby zostawić wiersze, których liczba je spełnia; oba naraz wymagają obu. Przeszukiwane są też wiersze metod i punkty ryzyka; Escape czyści.
- Sesje pokrycia i trend. Start Coverage Session — i każdy przebieg wczytany od tej chwili jest dodawany do poprzednich — wiersze, gałęzie i funkcje tak samo: to, co wykonał którykolwiek z nich, jest pokryte — więc testy jednostkowe, integracyjne i przejście przez aplikację pokazują, co razem osiągnęły. Pod paskiem narzędzi pokrycie wierszy z zapisanej historii jest rysowane jako trend, jeden punkt na przebieg.
- Compare with CI Baseline.
baseline.report wskazuje raport publikowany przez build gałęzi głównej — adres URL, pobierany z remote.headers, lub pobrany plik — i każde wczytanie jest z nim porównywane: karta paska stanu mówi, gdzie jest ten przebieg, a Compare with CI Baseline wymienia pliki, które się zmieniły. Punkt odniesienia przechodzi przez tę samą listę wykluczeń co przebieg, więc sumy porównują to samo z tym samym.
Naprawiono
- Raport przebiegu testów nie zawiera już nazwy użytkownika i komputera. Kolektor Code Coverage firmy Microsoft nazywa swój raport
<user>_<machine>_<stamp>.cobertura.xml, a ta nazwa widniała w drzewie i na każdym jego zrzucie ekranu; raport jest teraz przed wczytaniem przemianowywany na coverage.cobertura.xml.
- Przebieg testów kończył się błędem w Windows, gdy terminalem jest PowerShell. Cudzysłowy wokół
Code Coverage;Format=cobertura ginęły w drodze do pwsh, który czytał ; jako koniec polecenia; przepis jest teraz przekazywany terminalowi słowo po słowie i cytowany dla powłoki, którą uruchamia.
- O wygenerowanym pliku mówiono, że pominął go
fuciniCoverage.ignore. Każdy pominięty plik jest teraz liczony pod ustawieniem, które go pominęło — ignore, ignore.generated lub ignore.namespaces — więc pokazana nazwa to ta, którą trzeba zmienić.
- Nagłówek z makrami nie stoi już w drzewie na 100%. llvm-cov i gcov przypisują użycia makra wierszom, które je definiują; gałęzie i funkcje na wykluczonych wierszach odchodzą teraz razem z wierszami, a plik bez niczego mierzalnego jest usuwany z przebiegu i wymieniany w wyjściu (
FUCINI_EXCLUDE_001).
- Pięć raportów odrzucanych jako nieobsługiwany format jest rozpoznawanych. JaCoCo XML z Kovera, raport Stryker.NET, raport NCover, stary resultset SimpleCov i raport SonarQube z wieloma pustymi plikami są teraz rozpoznawane po tym, co mają na początku. Raport Clover lub SonarQube, którego ścieżki zawierają słowo
cobertura, nie jest już czytany jako Cobertura.
- Liczby zgodne z narzędziami, które je zapisały. Wynik gałęzi buildu MC/DC zgadza się z
llvm-cov report; gałęzie wyjątków LCOV 2 (BRDA:12,e0,1,3) są liczone; funkcja llvm-cov jest deklarowana tylko w pliku, który ją definiuje; blok Go wymieniony przez dwa pliki binarne testów sumuje swoje liczniki; decyzja Cobertura zgłaszana przez dwie klasy i wiersz JaCoCo wymieniony dwa razy zachowują wszystkie swoje gałęzie, raz.
- Drobniejsze. Plik śladu przerwany w trakcie zapisu nie gubi już pliku;
gcov -t na kilku plikach .gcda daje po pliku na każdy, instancje szablonów są czytane raz, a liczniki takie jak 1.20k z gcov -H są zachowywane; pliki GNATcoverage nie są już wszystkie zgłaszane jako zmienione od czasu pokrycia; oczekujący mutant Stryker ani przerwany przebieg PIT nie obniżają już wyniku.
Zmieniono
- Koniec z
FUCINI_ENCODING_001 przy każdym wczytaniu. Raport bez znacznika kolejności bajtów jest czytany jako UTF-8, tak jak zapisuje go każde narzędzie, bez uwagi, która by to mówiła.
Coverage Studio dla Visual Studio 1.2026.5 — obserwowane tam, gdzie pojawi się raport
2026-09-28
Dodano
- Wpis względny z symbolem wieloznacznym jest przeszukiwany na dowolnej głębokości.
*.lcov.info w coverageFile.paths znajduje plik, gdziekolwiek jest pod folderem bazowym, tak jak VS Code od zawsze czyta taki wpis; wpis bezwzględny — ${workspaceFolder}/build/coverage-merged/*.lcov.info, ** dla dowolnej głębokości — szuka dokładnie tam, gdzie wskazuje, jak dotąd.
- Obserwowane tam, gdzie pojawi się raport. Obserwacja obejmuje foldery wskazane w ustawieniach, niezależnie od tego, czy raport już tam jest: folder pliku o ścieżce bezwzględnej, foldery przed symbolem wieloznacznym — wraz ze wszystkim poniżej, gdy wzorzec sięga do podfolderów — i folder bazowy dla względnego symbolu wieloznacznego. Raport, który kompilacja tam zapisze, wczytuje się sam; zapis do jakiegokolwiek innego pliku w tych folderach jest ignorowany.
Naprawiono
- Raport JSON z llvm-cov był odrzucany jako nieobsługiwany format. Format jest rozpoznawany po pierwszych 4096 znakach, a llvm-cov zapisuje swój znacznik
"type": "llvm.coverage.json.export" na samym końcu; eksport, którego pierwszy rekord pliku niesie wiele gałęzi i zagnieżdżonych rozwinięć makr, nie miał w tym badanym początku nic innego rozpoznawalnego. Taki raport jest teraz rozpoznawany po tym, jak się zaczyna, {"data":[{"files":[, czego nie ma żaden inny format.
- To samo dla
gcov --json-format. gcov zapisuje funkcje pliku przed jego wierszami, a plik z kilkunastoma funkcjami również nie ma żadnego wpisu wiersza w badanym początku; teraz identyfikuje go własny klucz dokumentu gcc_version.
Coverage Studio for VS Code 1.2026.6 — symbol wieloznaczny w pełnej ścieżce, obserwowane tam, gdzie pojawi się raport
2026-09-28
Dodano
- Symbol wieloznaczny w bezwzględnym wpisie
coverageFile.paths. ${workspaceFolder}/build/coverage-merged/*.lcov.info wczytuje każdy taki plik w tym folderze, a ** oznacza dowolną głębokość: przeszukiwane są foldery przed pierwszym symbolem wieloznacznym, reszta to wzorzec pod nimi — tak jak edycja dla Visual Studio od zawsze czyta taki wpis. Dotąd wpisu bezwzględnego szukano dosłownie, tak jak go zapisano, więc wpis z gwiazdką nie pasował do niczego — a jako symbol wieloznaczny nie był też nigdy zgłaszany jako niepasujący do niczego. Raport, który pojawi się tam później, wczytuje obserwator albo odpytywanie, jak przy wpisie dosłownym; symbol wieloznaczny, który do niczego nie pasuje, nie jest zgłaszany, bo może czekać na kompilację.
Naprawiono
- Raport JSON z llvm-cov był odrzucany jako nieobsługiwany format. Format jest rozpoznawany po pierwszych 4096 znakach, a llvm-cov zapisuje swój znacznik
"type": "llvm.coverage.json.export" na samym końcu; eksport, którego pierwszy rekord pliku niesie wiele gałęzi i zagnieżdżonych rozwinięć makr, nie miał w tym badanym początku nic innego rozpoznawalnego. Taki raport jest teraz rozpoznawany po tym, jak się zaczyna, {"data":[{"files":[, czego nie ma żaden inny format.
- To samo dla
gcov --json-format. gcov zapisuje funkcje pliku przed jego wierszami, a plik z kilkunastoma funkcjami również nie ma żadnego wpisu wiersza w badanym początku; teraz identyfikuje go własny klucz dokumentu gcc_version.
Coverage Studio dla Visual Studio 1.2026.4 — dwa raporty, jedna odpowiedź i zieleń tam, gdzie pokryte
2026-09-26
Dodano
- Wybór lub łączenie raportów pliku. Kliknij plik prawym przyciskiem w oknie Coverage i wybierz Choose Coverage Source... — dostępne tam, gdzie plik mierzy więcej niż jeden wczytany raport — albo użyj Tools > Coverage Studio > Choose Coverage Source for This File...: każdy raport z własnymi liczbami, a potem Combine them — agree (pokryte tylko tam, gdzie wiersz wykonał każdy raport: jedna baza kodu, dwa kompilatory) i — union (pokryte tam, gdzie zrobił to którykolwiek: kilka zestawów testów jednej kompilacji), dla pliku, jego folderu lub wzorca. Wiersze, co do których raporty się różnią, są w kolorze morskim na marginesie i w Annotated Source, z tym, co powiedział każdy raport; wiersz w oknie podaje raporty i liczbę spornych wierszy, a pasek stanu i obie karty mówią, skąd pochodzą liczby.
- Czerwony, bursztynowy i zielony. Gutter: Coverage maluje każdy pokryty wiersz na zielono obok czerwonego i bursztynowego — tryb dla każdego, kto oczekiwał, że plik ze 100% będzie zielony. Pięć odcieni mapy cieplnej to ustawienia (
heatmap.colors, heatmap.colorsDark), a okno ustawień pokazuje podgląd każdego koloru już w trakcie wybierania.
Naprawiono
- Liczba pliku na pasku stanu jest tą z jego karty. Metryka, w której nic nie ma — MC/DC w pliku bez decyzji — liczyła się jako 100% w elemencie paska i wcale na karcie, którą on otwiera.
- Nagłówek z samymi stałymi nie pokazuje już 0% ani 100%. Dyrektywy preprocesora liczą się jako brak kodu, jak komentarze, gdy włączone jest
excludeComments.
Coverage Studio for VS Code 1.2026.5 — dwa raporty, jedna odpowiedź i zieleń tam, gdzie pokryte
2026-09-26
Dodano
- Wybór lub łączenie raportów pliku.
coverageFile.sources rozstrzyga, osobno dla każdego pliku, który z kilku wczytanych raportów się za nim wypowiada — albo je łączy: agree uznaje wiersz za pokryty tylko tam, gdzie wykonał go każdy raport, i oznacza kolorem morskim wiersze, co do których się różnią; union — tam, gdzie zrobił to którykolwiek. Choose Coverage Source... na wierszu widoku Coverage lub dla otwartego pliku zapisuje regułę za ciebie. Część płatnych planów; w Community rozstrzyga najnowszy raport.
- Czerwony, bursztynowy i zielony oraz tryb marginesu jednym kliknięciem. Tryb
coverage maluje pokryte wiersze na zielono; odcienie mapy cieplnej to ustawienia z podglądem na żywo w panelu ustawień; przycisk na pasku stanu i Alt+G przełączają margines kolejno: wyłączony, niepokryte, pokrycie i mapa cieplna.
Naprawiono
- Liczba pliku na pasku stanu jest tą z jego karty. Metryka, w której nic nie ma — MC/DC w pliku bez decyzji — liczyła się jako 100% w elemencie paska i wcale na karcie, którą on otwiera.
- Nagłówek z samymi stałymi nie pokazuje już 0% ani 100%. Dyrektywy preprocesora liczą się jako brak kodu, jak komentarze, gdy włączone jest
excludeComments.
Coverage Studio dla Visual Studio 1.2026.3 — nic do wyboru poza kodem
2026-09-24
Zmieniono
- Okno Licence pyta już tylko o kod. Cztery przyciski planów zniknęły: kod subskrypcji lub zaproszenia wskazuje pulę, a pula zna swój plan, więc nie było niczego, na co człowiek mógłby odpowiedzieć lepiej niż sam kod — a zaproszenie Business wklejone przy wciąż zaznaczonym Pro było odrzucane jako kod dla niewłaściwego planu. Wklej kod i naciśnij Activate.
Coverage Studio for VS Code 1.2026.4 — nic do wyboru poza kodem
2026-09-24
Zmieniono
- Enter Subscription Code pyta już tylko o kod. Pytanie o plan zniknęło: kod wskazuje pulę, a pula zna swój plan, więc serwer przejmuje resztę i nie odrzuca już kodu jako przeznaczonego dla niewłaściwego planu. Linki jednym kliknięciem w e-mailach są bez zmian; e-maile aktywacyjne nie mają już kroku „wybierz swój plan”, a ten sam kod aktywuje Coverage Studio dla Visual Studio bez potrzeby używania VS Code.
Coverage Studio dla Visual Studio 1.2026.2 — każde uruchomienie testów, każdy raport i co się zmieniło
2026-09-24
Dodano
- Pokrycie po każdym uruchomieniu testów. Collect Coverage in Test Explorer… kładzie obok rozwiązania jeden
.runsettings z kolektorem Cobertura Microsoftu — podejmowany sam, gdy Tools → Options → Test → Auto detect runsettings files jest włączone, albo wybrany raz w Test → Configure Run Settings; od tej pory każde uruchomienie w Test Explorer zapisuje raport pod projektem testowym i jest on wczytywany w chwili, gdy się pojawi, scalony ze wszystkim, co wskazują ustawienia. Nic nie podpina się pod Test Explorer, więc Visual Studio 2026 i Microsoft.Testing.Platform działają takie, jakie są. Run Tests with Coverage rozpoznaje dotnet test, vitest, jest, pytest, go, cargo, maven, gradle, phpunit i ctest, uruchamia je z włączonym pokryciem w oknie Output i wczytuje to, co zapisały; projekt testowy bez coverlet.collector jest uruchamiany z kolektorem dostarczanym z testowym SDK.
- Od ostatniego uruchomienia. Każde wczytanie jest porównywane z poprzednim: trójkąt na marginesie przy każdym wierszu, który zaczął lub przestał być wykonywany, trend obok wyniku i Compare with Last Run dla plików, których liczby się zmieniły.
history.enabled zachowuje uruchomienia między restartami; gitDiff.enabled ogranicza uruchomienie do wierszy zmienionych przez Twoją gałąź.
- Progi i Error List. Check Coverage Thresholds ocenia uruchomienie według
threshold.*; z compliance.diagnostics, problems.enabled, problems.perLine lub deadCode.enabled ustalenia trafiają do Error List obok tych od kompilatora, a każde otwiera swój plik.
- Raporty, eksporty i odznaka. Show Annotated Source otwiera aktywny plik jako stronę w obszarze dokumentów — każdy wiersz w swoim kolorze, ustalenia obok — przewijaną razem z edytorem w obie strony. Open HTML Report i Generate Full HTML Report zapisują uruchomienie do
htmlReport.outputDir i otwierają przeglądarkę. Export Coverage Report… zapisuje CSV na plik lub na funkcję, Markdown, LCOV, Cobertura, SARIF, odznakę SVG lub Fucini JSON. Generate Coverage Badge utrzymuje odznakę w repozytorium, po każdym wczytaniu z badge.autoUpdate.
- Risk hotspots i filtry wierszy w oknie Coverage, jak w VS Code: funkcje, w których złożony kod spotyka się z małym pokryciem, najgorsze najpierw; oraz menu rozwijane obok sortowania dla wszystkich plików, plików z lukami, plików nieprzetestowanych albo plików zmienionych od ostatniego uruchomienia.
- Plik ustawień w katalogu głównym rozwiązania.
fucini-coverage.json obok rozwiązania jest czytany po .vscode/settings.json i zapisywany przez okno ustawień, gdy to on jest plikiem, który istnieje — dla zespołu, który wolałby nie trzymać folderu .vscode. Obie edycje go czytają.
- .NET bez ceremonii.
ignore.generated pomija pliki projektanta, generowane, obj\ i migracje w każdej sumie; testRun.skipWhenTestsFail zachowuje na ekranie ostatnie dobre pokrycie, gdy uruchomienie kończy się na czerwono.
Jeszcze nie w tej edycji
- Panel Test Coverage to API VS Code, a Solution Explorer nie może pokazywać odznak. Compare Two History Runs nadejdzie, gdy poproszą o niego subskrybenci.
Coverage Studio for VS Code 1.2026.3 — punkty ryzyka, filtry i .NET bez pakietu
2026-09-24
Dodano
- Które pliki pokazywać. Drugie menu rozwijane na pasku narzędzi widoku Coverage, obok sortowania: wszystkie pliki, pliki z lukami, pliki nieprzetestowane albo pliki, których liczby zmieniły się od poprzedniego uruchomienia. Foldery podążają za swoimi plikami i zachowują własne liczby. W każdym planie.
- Risk hotspots. Pod drzewem: funkcje, w których złożony kod spotyka się z małym pokryciem, najgorsze najpierw, a każda otwiera swój plik na tej funkcji. Funkcja kwalifikuje się przez wynik CRAP —
hotspots.crapThreshold, domyślnie 30, liczba zaproponowana przez autorów metryki — albo przez samą złożoność cyklomatyczną, hotspots.complexityThreshold, domyślnie wyłączone. Community widzi liczbę i najgorszy wynik; lista rankingowa jest w Pro.
dotnet test bez pakietu. Run Tests with Coverage czyta najpierw pliki projektów: gdzie żaden nie odwołuje się do Coverleta, uruchomienie używa własnego kolektora Microsoftu — --collect:"Code Coverage;Format=cobertura" — dostarczanego z Microsoft.NET.Test.Sdk, a jego raport jest wczytywany jak raport Coverleta.
- Generowane pliki .NET są pomijane.
ignore.generated, domyślnie włączone, usuwa *.Designer.cs, *.g.cs, *.generated.cs, *.razor.g.cs, AssemblyInfo, globalne usingi, wszystko pod Migrations/ i pod obj/ z każdej sumy, strony i eksportu. Plik projektanta, którego nikt nie testuje, nie kosztuje już rozwiązania jego progu.
- Nieudane uruchomienie zachowuje ostatnie dobre pokrycie. Z
testRun.skipWhenTestsFail uruchomienie, które kończy się nieudanym testem, zostawia pokrycie na ekranie takie, jakie było, i mówi to w panelu Output. Domyślnie wyłączone.
Zmieniono
- Uruchomienie z Test Explorer jest znajdowane samo. Bez żadnej konfiguracji dobrze znane nazwy obejmują teraz folder
TestResults/<run>/ każdego projektu testowego, nie tylko folder samego obszaru roboczego, oraz <user>_<machine>_<date>.cobertura.xml kolektora Microsoftu obok pliku Coverleta. Rozwiązanie .NET, którego testy uruchomiono w Visual Studio, pokazuje swoje pokrycie przy pierwszym otwarciu; każdy folder uruchomienia jest wczytywany, a scalanie zachowuje dla każdego pliku wynik najnowszego uruchomienia.
Coverage Studio dla Visual Studio 1.2026.1 — to samo pokrycie, w drugim IDE
2026-09-23
Dodano
- Drugie rozszerzenie, dla Visual Studio 2022 i 2026 — Community, Professional i Enterprise. Ten sam czytnik co w edycji dla VS Code, więc ten sam raport daje te same liczby, co do cyfry, w obu edytorach; i te same ustawienia
fuciniCoverage.*, czytane z .vscode/settings.json oraz z własnych ustawień użytkownika VS Code, gdy jest na maszynie. Nie korzysta z własnego pokrycia kodu Visual Studio: w Visual Studio 2022 to funkcja Enterprise, a w Community i Professional to jedyne pokrycie, jakie IDE pokaże. - W edytorze: pasek na marginesie na wiersz — czerwony nigdy się nie wykonał, bursztynowy częściowo, mapa cieplna według liczby odwiedzin — liczniki w wierszu, wiersz nad każdą funkcją z jej pokryciem, złożonością, wynikiem CRAP i MC/DC, paski na pasku przewijania, podpowiedź mówiąca, która gałąź nie została wykonana, i kropka na wierszu zmienionym od czasu raportu.
- Okno Coverage (View → Other Windows → Coverage): każdy plik ze swoimi metrykami i jeden wynik dla wszystkich, sortowalny, z niezmierzonymi plikami poniżej; elementy paska stanu
Coverage i File, każdy otwierający pełną kartę. - Polecenia w Tools → Coverage Studio, z dwuklawiszowymi akordami po
Ctrl+Shift+U: N/P dla następnego i poprzedniego niepokrytego wiersza, B dla następnej częściowo przetestowanej decyzji, R do przeładowania. Tryb obserwacji przeładowuje, gdy zmieni się plik zapisywany przez Twój build. - Getting Started, sześć kroków z przyciskiem do każdego, w 18 językach; za pierwszym razem otwiera się sam.
- Ustawienia z zębatki na pasku narzędzi okna Coverage, zapisujące ustawienia użytkownika tej edycji albo
.vscode/settings.json folderu i zachowujące komentarze edytowanego pliku. - Licencja: w cenie każdego płatnego planu. Maszyna, na której Coverage Studio dla VS Code jest aktywowane, nie potrzebuje nic więcej — klucz jest znajdowany sam; wszędzie indziej Tools → Coverage Studio → Licence… przyjmuje kod subskrypcji z e-maila aktywacyjnego. Bez subskrypcji pokrycie nie jest czytane: w Visual Studio nie ma darmowego poziomu.
Jeszcze nie w tej edycji
- Run Tests with Coverage i panel Test Coverage to API VS Code; Solution Explorer nie może pokazywać odznak. Widok Annotated Source, raport HTML i eksporty, Check Thresholds, wpisy w Error List, historia i trend oraz pokrycie diff nadejdą w kolejności, w jakiej poproszą o nie subskrybenci.
Coverage Studio for VS Code 1.2026.2 — Pierwsze kroki, i dwa edytory na jednej subskrypcji
2026-09-23
Dodano
- Przewodnik. Get started with Coverage Studio — w Help → Welcome → Walkthroughs, otwierany sam po instalacji — prowadzi nowego użytkownika w sześciu krokach od raportu pokrycia do wierszy, których nikt nie testuje, każdy z przyciskiem do polecenia, o którym mówi. We wszystkich osiemnastu językach.
- Identyfikator instalacji jest zostawiany tam, gdzie czyta go Coverage Studio dla Visual Studio. Edycja dla Visual Studio weryfikuje klucz w
license.key względem tego samego odcisku i nie może czytać magazynu stanu tego rozszerzenia; przy każdej aktywacji identyfikator jest teraz zapisywany także obok globalnego magazynu rozszerzenia, więc maszyna aktywowana w VS Code nie potrzebuje drugiej aktywacji w Visual Studio. Losowy UUID, z niczym niezwiązany, nigdy nigdzie niewysyłany.
Zmieniono
- Zwrot kończy subskrypcję. Zatwierdzony zwrot albo obciążenie zwrotne anuluje teraz subskrypcję natychmiast, a jej kod aktywacyjny nie wydaje więcej kluczy; zwroty są jeden na klienta. Klucze już na maszynie działają do własnego wygaśnięcia, jak dotąd. Polityka zwrotów mówi dokładnie, co się dzieje.
Coverage Studio for VS Code 1.2026.1 — Nazwy plików, które zawsze da się przeczytać
2026-09-21
Naprawiono
- Nazwy plików w widoku Coverage są czytelne przy każdej szerokości. Nazwa była jedyną częścią wiersza, która się kurczyła — do siedmiu znaków w zwykłym pasku bocznym. Teraz jest rysowana w całości, a kolumny metryk, wynik i pasek wsuwają się pod nią od lewej, zanikając na cięciu, tak aby pół liczby nigdy nie wyglądało jak cała. Każda wartość nadal jest w podpowiedzi wiersza.
- Znacznik „plik został zmieniony” nadąża za plikiem. Po wczytaniu podążał za pierwszą edycją i pierwszym przywróceniem, a potem nic go nie ruszało aż do następnego wczytania. Teraz dociera każdy zapis i każda zmiana na dysku.
- Pasek narzędzi widoku Coverage nie łamie już etykiet swoich przycisków. W wąskim pasku bocznym pasek zawija się teraz między swoimi kontrolkami, a pole sortowania przechodzi do własnego wiersza.
- Odznaka pokrycia jest darmowa także w selektorze eksportu. Generate Coverage Badge zawsze zapisywał odznakę SVG na każdym poziomie, podczas gdy Export Coverage Report… odmawiał tego samego pliku w Community. Teraz zapisują go oba.
- Show Worst-Covered Folders jest licencjonowany tak jak dwie pozostałe listy. Nic się nie zmienia w Community, gdzie wszystkie trzy są darmowe i nieliczone, ani dla żadnego już wydanego klucza.
Dodano
- Minimalna obsługiwana wersja. Rozszerzenie odczytuje teraz, mniej więcej raz w tygodniu, niewielką podpisaną politykę z naszego serwera licencji. Gdy kompilacja jest starsza niż najstarsza wciąż obsługiwana, okres próbny i poziom bezpłatny zatrzymują się i proszą o aktualizację; płatna licencja otrzymuje datę i najpierw działa dalej przez okres karencji. Odczyt nie wysyła niczego o Tobie ani o Twojej instalacji, a instalacja, która nie może połączyć się z serwerem, nigdy nie jest z tego powodu zatrzymywana. Obecnie nie ustawiono żadnego minimum.
Zmieniono
- Od tego wydania licencja jest własnościowa. Rozszerzenie było publikowane na warunkach MIT, co nigdy nie pasowało do produktu sprzedawanego w subskrypcji. Opublikowaną kompilację można instalować i używać w ramach swojego planu, także komercyjnie; nie wolno jej kopiować, modyfikować, rozpowszechniać ani poddawać inżynierii wstecznej. To, co wytwarza z Twoich danych — raporty, eksporty, odznaki — należy do Ciebie, a dawny warunek podania autorstwa znika. Kopia wcześniejszego wydania pozostaje na warunkach, z którymi przyszła.
- Przycisk akcji ścieżki (⋯) nie zajmuje miejsca, dopóki nie wskażesz wiersza. 25 pikseli, które rezerwował w każdym wierszu, przypada teraz nazwie pliku; pojawia się tuż za nazwą po najechaniu, i nic w wierszu się nie przesuwa.
Coverage Studio for VS Code 1.2026.0 — Warunki, mutanty i testy stojące za wierszem
2026-09-20
Naprawiono
- Pliki śledzenia LCOV 2 wymieniają każdą funkcję raz.
FN:<wiersz>,<wiersz końcowy>,<nazwa> jest czytany tak, jak zapisuje go lcov 2.0 — wcześniej każda funkcja pojawiała się dwa razy, raz jako nigdy niewywołana i raz w wierszu 0 — a wraz z nim czytane są pary FNL:/FNA: z lcov 2.2.
- Szablon C++ nie jest już malowany jako nigdy niewykonany dlatego, że jedna instancjacja taka była, a funkcja pełna makr znów jest jedną funkcją zamiast jednej na makro.
- Teksty zgody mówią, co instalacja naprawdę wysyła: żadnej comiesięcznej strony Twojego kodu, a podsumowanie użycia niesie kod żądania, na który wydano Twój klucz.
Dodano
- Pokrycie warunków jest osobną metryką.
a && b to jedna decyzja i dwa warunki, a zestaw testów może przejść obie gałęzie, ani razu nie widząc b fałszywego. Ma teraz własny wiersz, kolumnę, eksporty, odznakę, wagę w wyniku (3, między gałęziami a MC/DC) i próg — czytane z BullseyeCoverage, eksportu cond z TRACE32 i -fcondition-coverage w GCC 14.
- Mutanty tam, gdzie są. Raporty PIT i Stryker czytane są mutant po mutancie: te, które przeżyły, są oznaczane we własnym wierszu w edytorze, ze zmianą i testami, które go wykonały, w podpowiedzi, oraz wymieniane w raporcie HTML i w kodzie z adnotacjami.
- Które testy wykonały ten wiersz. coverage.py z
--show-contexts i OpenCover z -coverbytest mówią, które testy dotarły do wiersza; podpowiedź z liczbą trafień je wymienia.
- Część wykonanego wiersza, która nigdy nie zadziałała, jest podbarwiona w edytorze, a funkcje w C i C++ dostają złożoność i wynik CRAP policzone z danych o gałęziach, które llvm-cov już zawiera.
- Projekty JaCoCo, Cobertura i Coverlet ładują się przy pierwszym otwarciu, bez żadnego ustawienia — także tam, gdzie domyślnie piszą Maven, Gradle i
dotnet test.
- Każda metryka obok każdego pliku, przy dowolnej szerokości, uporządkowana według wagi w Twoim wyniku, a to, co się nie mieści, przewija się zamiast znikać — oraz licznik na ikonie Coverage, gdy plik śledzenia przeładuje się, kiedy patrzysz gdzie indziej.
- Kanał wersji przedpremierowych, do którego można się zgłosić, i jeden przycisk na pasku tytułu edytora, który wyłącza kolorowanie pokrycia i przywraca dokładnie to, co było.
Zmieniono
- Bullseye i TRACE32: pokrycie gałęzi nie obejmuje już warunków. Decyzje są pokryciem gałęzi, a warunki pokryciem warunków, więc liczba gałęzi takiego projektu się zmienia, a wraz z nią wynik złożony. Ustaw
whmWeights.conditions na 0, aby otrzymać wynik jak dawniej.
- Darmowy poziom Community ma tygodniowy przydział: po pięć tygodniowo na każdą mierzoną czynność, gdzie było dwadzieścia dziennie, a na granicy proponowana jest subskrypcja albo 7-dniowy karnet. Instalacja już używana zachowuje stare limity przez 30 dni i jest o tym raz informowana, z datą.
- Okres próbny i darmowy poziom prowadzą rejestr użycia z serwerem licencji: skrót identyfikatora maszyny z VS Code, edycja, dzień rozpoczęcia oceny i liczniki mierzonych czynności — i nic więcej; nigdy przy licencji płatnej i nigdy z czekaniem. Wymiana za telemetrię to teraz jednorazowe 30 dni.
- Comiesięczna strona kodu źródłowego zniknęła — nie jest zbierana, przechowywana ani wysyłana dla nikogo, a tę pozostawioną przez wcześniejszą wersję ta usuwa przy pierwszym uruchomieniu.
0.2026.82 — Progi dopasowane do Twojego projektu i wszystko, co zawierają Twoje raporty
2026-09-17
Naprawiono
- Mapa cieplna czyta się we właściwą stronę w ciemnym motywie. Jej skala biegła od bladej żółci do ciemnego brązu, więc najgorętsza pętla miała najmniej widoczny pasek. Ciemny motyw ma teraz własną skalę, od przygaszonej oliwki do żywego pomarańczu.
- Podpowiedź MC/DC po najechaniu znów pokazuje szczegóły, a decyzja z llvm-cov poprawnie liczy swoje warunki. Aktualny VS Code zwijał podpowiedź do jednego wiersza; z kolei
(a && b) || c było wypisywane z jednym warunkiem na poziomie 100% pod nagłówkiem, który słusznie podawał 2 z 3 par. - Funkcje C++ noszą nazwy takie, jakie im nadano:
clamp_to<int> i gearbox::next_gear zamiast linkerowego ??$clamp_to@H@@YAHHHH@Z, dla llvm-cov, lcov i gcov. - Liczby wierszy Istanbul zgadzają się z nyc, XML z
dotnet-coverage jest odczytywany, wiersze SimpleCov :nocov: są wykluczane, a nie psute, a raport zawierający jedynie podsumowanie zachowuje swoje wartości niezależnie od kolejności odczytu raportów. - Obszary robocze z wieloma folderami głównymi: raport HTML nie wymienia już folderu dwukrotnie, widok Coverage opatruje folder obszaru roboczego jego nazwą, a reguła
pathRemap może zawierać zarówno ${workspaceFolder}, jak i ${workspaceRoot}.
Dodano
- Pokazywane jest wszystko, co zawiera raport. Wywołania funkcji, kod obiektowy i wynik mutacyjny otrzymują kolumnę w widoku Coverage, w raporcie HTML oraz w eksportach CSV i Markdown, wiersz w kartach paska stanu i odznakę w źródle z adnotacjami — a metryka, której raport nie zawiera, jest pomijana, zamiast być drukowana jako zero.
- Złożoność i CRAP. Tam, gdzie raport zawiera złożoność cyklomatyczną (OpenCover, JaCoCo, Clover, Cobertura), każda funkcja otrzymuje wynik CRAP w swoim CodeLens, plik otrzymuje Max CRAP z odnośnikiem do metody, a raport HTML wymienia Riskiest Methods.
- Więcej z każdego formatu: nazwane ramiona gałęzi, wykluczone wiersze, zakresy kolumn w obrębie wiersza, narzędzie, wersja i data raportu oraz ostrzeżenia, które narzędzie w nim zapisało.
- Opcjonalne wagi dla kodu obiektowego i wyniku mutacyjnego w wyniku złożonym, obie równe
0, dopóki ich nie ustawisz.
Zmieniono
- Domyślne progi nie wynoszą już 100%. Próg, którego nie ustawiono, oznacza teraz: wiersze 80, funkcje 80, regiony 75, gałęzie 70 i wynik złożony 75, bez bramki dla MC/DC, instancjacji, wywołań funkcji i kodu obiektowego — tyle, ile można wymagać od zwykłego projektu.
fuciniCoverage.threshold.profile: "safety" przywraca każdą bramkę na poziom 100, dokładnie jak dotąd, a próg ustawiony samodzielnie ma pierwszeństwo przed każdym z profili. Jeśli polegano na dawnych wartościach domyślnych, ocena jest łagodniejsza, dopóki nie zostanie wybrany profil safety; instalacja, która działała już wcześniej, jest o tym informowana jeden raz, wraz z przyciskiem, który go ustawia. - Metryka bez bramki pokazuje w kartach neutralną kreskę zamiast znaku zaliczenia lub krzyżyka, a panel ustawień pokazuje podgląd werdyktu według bramek faktycznie obowiązujących.
0.2026.81 — Dokładne procenty i raport, który można wysłać
2026-09-16
Naprawiono
- Pokrycie w buforze z niezapisanymi zmianami znów się zgadza. Przebieg wczytany, gdy plik miał niezapisane edycje, przesuwał każdy znacznik, podpowiedź i CodeLens o tyle wierszy, o ile te edycje je zepchnęły. Edycje są teraz odtwarzane z pliku na dysku, a cały wiersz wklejony nad wierszem nie liczy już tego wiersza jako edytowanego.
- Scalenia i powtórzone rekordy LCOV się sumują. Nowszy plik śladu nie zachowuje już podsumowań gałęzi i MC/DC starszego przebiegu, a plik wymieniony dwukrotnie w jednym pliku śladu jest łączony tak, jak łączy go genhtml.
- Klucz licencji zostaje na swojej maszynie. Settings Sync nie przenosi go już na inne instalacje, gdzie blokował pokrycie; wygasły klucz Business, Enterprise lub Pro Plus odnawia się sam do 45 dni po wygaśnięciu.
- Zdalne pliki śladu są pobierane ostrożniej.
remote.headers zostają przy swoim źródle mimo przekierowań, pobieranie poddaje się po 30 sekundach, strona logowania jest odrzucana zamiast buforowana, a okno otwarte offline wczytuje ostatnią pobraną kopię. Samoaktualizacja instaluje tylko własną edycję. - Parsery: liczniki wierszy llvm-cov zgadzają się z
llvm-cov show, decyzje OpenCover z różnych metod już się nie nadpisują, xccov, TRACE32 i EMMA zachowują swoje liczby wierszy, klasy Cobertura dzielące plik są jednym plikiem, zbiorcze raporty JaCoCo są odczytywane, a mapowanie ścieżek rozwiązuje .. i porównuje całe segmenty. - W edytorze: historia jest prowadzona per obszar roboczy, znaczniki zostają na prawdziwych plikach, a nie na panelu HEAD edytora różnic, wiersze za końcem pliku nie są malowane, odznaki Eksploratora w Windows działają dla ścieżek
C:\…, a duże przebiegi przeszukuje się szybciej.
Dodano
- Wyślij raport diagnostyczny. Oferują go powiadomienia o nieudanym wczytaniu, zdalnym pobraniu, scaleniu, porównaniu historii lub czacie. Pokazuje dokładnie ten JSON, który zostałby wysłany, z opcjonalną próbką pliku 4 KB, komentarzem i adresem zwrotnym, i nie wysyła niczego, dopóki nie klikniesz Wyślij.
- Raporty błędów. Błąd
FUCINI_* jest zgłaszany bez zawartości plików, ścieżek ani nazw, gdy poziom telemetrii VS Code to all lub error. Trzy wiersze dziennika mają własne kody: FUCINI_REMOTE_002, FUCINI_REMOTE_003 i FUCINI_GITDIFF_002, każdy opisany w podręczniku użytkownika.
Zmieniono
- Każdy procent pokrycia ma dwa miejsca po przecinku, obcinane zamiast zaokrąglane:
87.43%, a 100.00% tylko wtedy, gdy pokrycie wynosi dokładnie 100. - Progi rozstrzygają na dokładnej wartości. Dotąd każdy procent był najpierw zaokrąglany do liczby całkowitej, więc 89,6% przechodziło próg 90%. Projekt, który przechodził tylko dzięki zaokrągleniu, pokaże teraz NON-COMPLIANT, dopóki jego pokrycie naprawdę nie osiągnie progu.
- Telemetria jest codzienna. Każda instalacja wysyła codziennie mały komunikat licencyjny na poziomie telemetrii VS Code
all; przy włączonym telemetry.enabled podsumowanie użycia wychodzi codziennie zamiast co miesiąc. Instalacje, które odblokowały funkcje za telemetrię, są pytane, zanim ich warunki się zmienią.
0.2026.80 — Aktualizacja, którą widać
2026-09-14
Dodano
- Widok Coverage informuje o dostępnej aktualizacji — i nie przestaje. Pasek nad banerem licencji podaje nową wersję obok tej, którą masz, z tymi samymi trzema przyciskami co powiadomienie o aktualizacji: „Pobierz & zainstaluj”, „Zobacz listę zmian” i „Pomiń tę wersję”. Ikona widoku na pasku aktywności dostaje też plakietkę, więc widać ją nawet przy zamkniętym widoku. Powiadomienie pojawiało się tylko raz, przy automatycznym sprawdzeniu, a kliknięcie gdziekolwiek indziej ukrywało je do następnego sprawdzenia dzień później; pasek zostaje, dopóki aktualizacja nie zostanie zainstalowana lub pominięta albo
fuciniCoverage.update.checkForUpdates nie zostanie wyłączone, i przetrwa przeładowanie okna.
0.2026.79 — Jeden ping dziennie
2026-09-14
Zmieniono
- Małe pingi wychodzą najwyżej raz dziennie, razem. Aktualizacja, zmiana licencji, nowy format pokrycia i plik, którego nie dało się odczytać, były wcześniej osobnymi pingami, wysyłanymi w chwili zauważenia — a w niektórych instalacjach zauważanymi ponownie w każdej sesji: odebrane stanowisko zgłaszało odebranie przy każdym uruchomieniu, a przełączanie się między obszarami roboczymi z różnymi formatami za każdym razem zgłaszało „nowy” zestaw. Teraz są zbierane i wysyłane jako jeden ping, najwyżej raz dziennie. Dzień, w którym nie ma nic do zgłoszenia, nie wysyła niczego.
- Zgłaszane jest tylko to, co naprawdę się zmieniło. Licencja, która w ciągu dnia zmieni się i wróci do poprzedniego stanu, nie zgłasza niczego, a formaty to wszystkie formaty, jakie instalacja kiedykolwiek wczytała, a nie tylko te z ostatniego obszaru roboczego. Ping instalacji i powiadomienie o odinstalowaniu nadal wychodzą natychmiast i nie jest zbierane nic nowego.
- Własny przełącznik telemetrii w VS Code obejmuje teraz także małe pingi. Gdy
telemetry.telemetryLevel ma wartość off, dla dziennego pingu nic nie jest zbierane ani wysyłane; dotąd respektowały go tylko miesięczne podsumowanie i powiadomienie o usunięciu. Jednorazowy ping instalacji się nie zmienia.
- Miesiąc, który kończy się, gdy edytor stoi bezczynnie, i tak zostaje zgłoszony. Miesięczne podsumowanie było sprawdzane tylko po wczytaniu pokrycia, więc instalacja, której przestano używać, nigdy nie wysyłała swojego ostatniego miesiąca. Teraz jest też sprawdzane co godzinę, gdy VS Code jest otwarty — nadal tylko przy włączonej telemetrii i nadal najwyżej raz na 30 dni.
Naprawiono
- Ping odrzucony przez serwer nie liczy się już jako wysłany. Każda odpowiedź serwera, także błąd, była traktowana jak doręczenie, więc odrzucony dzienny ping tracił to, co zebrał, a odrzucony ping instalacji nie był ponawiany. Teraz liczy się tylko udana odpowiedź; odrzucony dzienny ping lub miesięczne podsumowanie zostaje zachowane i ponowione dzień później.
0.2026.78 — Nowe czternaście dni
2026-09-13
Zmieniono
- Każdy okres oceny jednorazowo dostaje nowe 14 dni. Przy pierwszym uruchomieniu tego wydania okres próbny zostaje ponownie otwarty w każdej instalacji Pro bez licencji płatnej — niezależnie od tego, czy skończył się dawno, czy zostało mu jeszcze kilka dni — i trwa 14 dni od tego dnia. Gdy to nastąpi, informuje o tym krótkie powiadomienie. Licencja płatna pozostaje nietknięta, a edycja Community, która nie ma okresu próbnego, pozostaje bez zmian.
- Licencja płatna pokazuje „Aktywowano”, na zielono. Baner licencji pokazywał dotąd subskrybentowi „Aktywowano — pozostało 30 dni”. Klucz subskrypcji obowiązuje do końca opłaconego okresu i jest odnawiany razem z nim, więc to odliczanie nigdy nie przestałoby wyglądać jak okres próbny, który zaraz się skończy. Nagłówek mówi teraz po prostu Aktywowano, data widnieje w szczegółach jako „Obowiązuje do”, a odliczanie wraca dopiero w ostatnim tygodniu przed wygaśnięciem klucza, obok istniejącej już uwagi o zbliżającym się odnowieniu.
0.2026.77 — Wklej kod, to wszystko
2026-09-12
Dodano
- „Enter Subscription Code” — i o nic więcej nie pytamy. Wybierz plan, wklej kod z e-maila o zakupie, potwierdź — a klucz licencyjny zostanie wystawiony i zastosowany za ciebie. Dotąd jedyna droga z samego edytora prowadziła przez kwestionariusz oceniający — imię, e-mail, typ konta, firma, ankieta — a to niewłaściwy formularz, by stawiać go przed kimś, kto już kupił. Drugą drogą był link
vscode:// w e-mailu, a ostrożność przed takim kliknięciem jest rozsądna, a nie lękliwa: taki link może wywołać dowolna odwiedzana strona, i właśnie dlatego aktywacja prosi o potwierdzenie. Polecenie jest w palecie poleceń, a także stanowi przycisk na banerze licencji w panelu pokrycia i w oknie aktywacji — w każdym stanie, bo licencja przenosi się między maszynami, a zakup w trakcie okresu próbnego jest przypadkiem zwyczajnym, a nie wyjątkiem.
- Sposób, by zobaczyć plany wprost z okresu próbnego. Strona z cenami była dostępna z ekranów wersji darmowej, ale nie z okna aktywacji ani z banera licencji — z jedynego miejsca, w które naprawdę patrzy ktoś widzący „Zostały 3 dni”. Takiemu czytelnikowi proponowano kwestionariusz i wskazówkę o
settings.json, a ceny żadnej.
Zmieniono
- Okno aktywacji i baner licencji nie zaczynają się już od
FCK1. Oba otwierały się wcześniej kodem żądania i wskazówką „wklej klucz do settings.json”, a to droga na wypadek, gdy do naszego serwera licencji w ogóle nie można się dostać. Pokazana jako pierwsza, czytała się jak instrukcja — więc klient z kodem subskrypcji FCB1… trafiał do „Enter Activation Key”, jedynego pola, które z pewnością go odrzuci. Oba są nadal na miejscu, poniżej dróg pasujących do kogoś, kto już kupił, i opisane jako to, czym rzeczywiście są.
0.2026.76 — Polecenie, które wskazywał e-mail
2026-09-12
Naprawiono
- „Request Activation Key” to teraz naprawdę polecenie. E-mail z potwierdzeniem zakupu — i strona aktywacji, w każdym języku — mówią, że jeśli link „jeden klik” nie przetrwa programu pocztowego, można uruchomić Fucini Coverage: Request Activation Key z palety poleceń, wybrać plan i wkleić kod. Ta nazwa należała do paska tytułu panelu i do samego odnośnika, nigdy do polecenia, więc w palecie nie było pod nią nic — a najbliższe dopasowanie po nazwie, Enter Activation Key, przyjmuje klucz
FCK1… wystawiany przez nasz serwer, a nie kod FCB1…, który nosi e-mail. Wykonanie instrukcji prowadziło dokładnie do tego jednego pola, które z pewnością odrzuci to, co jest w ręku. Teraz jest to prawdziwe polecenie.
- Okno aktywacji udostępnia Poproś o licencję… także wtedy, gdy okres próbny lub klucz są jeszcze aktywne. Wcześniej przycisk był ukrywany, dopóki jedno z nich nie wygasło, z założeniem, że działająca instalacja nie ma powodu łączyć się z serwerem licencji. Zakup w trakcie okresu próbnego jest jednak przypadkiem zwyczajnym, a nie wyjątkiem, i kupujący w takiej sytuacji nie miał z okna żadnej drogi do pola, w które wpisuje się kod: dwa pozostałe przyciski prosiły o klucz, który powstaje dopiero po wykorzystaniu kodu.
0.2026.75 — Paleta dla osób z daltonizmem
2026-09-12
Dodano
- Paleta dla osób z daltonizmem. Ustaw
colorScale.preset na colorblind, a pokrycie będzie rysowane cynobrem, pomarańczem i błękitem (paleta Okabe–Ito) zamiast czerwieni, bursztynu i zieleni — gradient, paski na marginesie, podświetlenie wierszy, plakietki w Eksploratorze i znaczniki od ostatniego uruchomienia. Kolor ustawiony samodzielnie ma pierwszeństwo.
0.2026.74 — Pokrycie filtrowane według testu
2026-09-12
Dodano
- Filtrowanie pokrycia według testu we własnym widoku Test Coverage w VS Code. Gdy plik śledzenia nazywa swoje testy — sekcje
TN: w lcov — każdy test staje się elementem pod Fucini Coverage w Test Explorer, każdy plik w widoku Test Coverage wymienia testy, które coś w nim wykonały, a wybranie jednego pokazuje wiersze, do których dotarł ten test. ${command:…} w ustawieniach ścieżek. ${command:cmake.buildDirectory}/coverage.info podąża za wybranym zestawem CMake. Polecenie uruchamia się przed każdym wyszukiwaniem, najwyżej przez pięć sekund i tylko w zaufanym obszarze roboczym; polecenie, które zawiedzie, zostawia zmienną w zapisanej postaci, a dane wyjściowe mówią dlaczego.- Szybki start w 30 sekund i porównanie z alternatywami otwierają teraz stronę w Marketplace i stronę główną.
Naprawiono
- Plik śledzenia, który zapisał plik osobno dla każdego testu, liczył go osobno dla każdego testu. Rekordy są teraz sumowane w obrębie pliku śledzenia, tak jak czyta je genhtml: plik liczy się w sumach raz, a przy kilku wczytanych plikach śledzenia nie giną wiersze żadnego testu.
0.2026.73 — Podpisane aktualizacje i klucz, który przetrwa zmianę edycji
2026-09-11
Naprawiono
- Identyfikator instalacji jest teraz zapisywany, zanim cokolwiek go użyje. Kompilacja 2 wersji 0.2026.72 sprawiła, że identyfikator nie jest już ustalany od nowa przy każdym wywołaniu, ale uruchamianie nadal nie czekało na jego zapis, więc okno zamknięte tuż po otwarciu wciąż mogło go stracić — a wraz z nim odcisk maszyny, do którego przypisany jest klucz aktywacyjny. Teraz uruchamianie czeka.
- Przejście z Pro na Community nie unieważnia już klucza aktywacyjnego. Każda edycja ma własną pamięć rozszerzenia, więc Community zaczynała z nowym identyfikatorem instalacji i nowym odciskiem, podczas gdy klucz w ustawieniach — w tym ten, o który przejście właśnie poprosiło dla bezpłatnego odblokowania — był przypisany do starego. Teraz przejście przekazuje identyfikator.
Bezpieczeństwo
- Aktualizacje z fucini.software są podpisane i sprawdzane przed instalacją. Każdy plik
.vsix w kanale aktualizacji ma skrót SHA-256 i podpis Ed25519 wykonany kluczem, którego nigdy nie ma na serwerze WWW. Wbudowany mechanizm aktualizacji i przejście na Community sprawdzają oba względem pobranego pliku i odrzucają wszystko inne — stronę błędu proxy, przerwane pobieranie, starszą kompilację z pamięci podręcznej albo plik, który nie pochodzi od nas. Samo HTTPS tego nie zapewnia: firmowe proxy inspekcjonujące TLS ponownie podpisuje każde połączenie, które przez nie przechodzi. - Każde wydanie ma własną nazwę pliku. Kanał aktualizacji wskazuje teraz na plik
.vsix z numerem wersji zamiast na plik nadpisywany przy każdym wydaniu, więc pamięć podręczna ignorująca Cache-Control nie poda kompilacji z zeszłego miesiąca jako bieżącej. Linki na stronie pobierania pozostają bez zmian.
0.2026.72 — Decyzje przetestowane tylko w jedną stronę
2026-09-10
Dodano
- Skok do decyzji przetestowanych tylko w jedną stronę. Next Partly-Tested Decision i jej poprzedni odpowiednik przechodzą po rozgałęzieniach, których część gałęzi wykonano, a części nigdy. To luka, której nawigacja po nieobjętych wierszach pokazać nie może: wiersz, którego instrukcja się wykonała, jest objęty i pozostaje objęty, ile by jego gałęzi nigdy nie wybrano —
if (a && b) osiągnięty raz z fałszywym a jest objęty w 100% wierszowo i przetestowany w połowie. Jeden przystanek na decyzję, a nie na gałąź, bo gałęzie if/else mogą dzielić strony, a skok do piątej gałęzi switcha mówi mniej niż skok do samego switcha. Decyzje, do których nie dotarła żadna gałąź, zostają poleceniom od nieobjętych wierszy, które i tak się tam zatrzymują — a plik, w którego raporcie rozgałęzień w ogóle nie ma, mówi to wprost, zamiast twierdzić, że każdą decyzję przetestowano w obie strony.
Reload Coverage odczytuje na nowo to, co już wczytano. Przy wyłączonym śledzeniu jedyną drogą do świeżych liczb po ponownym uruchomieniu testów było Load Coverage, które ponawia wykrywanie i może wrócić z innym zestawem niż ten na ekranie. To polecenie odczytuje dokładnie to, co jest wczytane teraz, łącznie z plikami śledzenia wybranymi ręcznie, których wykrywanie nigdy by już nie znalazło.
Copy Coverage Summary ujmuje przebieg w tabelę Markdown. Najsłabiej pokryty plik pierwszy, z wierszem sum, gotowe do wklejenia w pull requeście. Kolumny rozgałęzień i MC/DC pojawiają się tylko wtedy, gdy coś w przebiegu je zmierzyło: kolumna myślników czyta się jako zerowe pokrycie, a nie jako niezmierzone, co jest przeciwieństwem prawdy.
Naprawiono
- Identyfikator instalacji mógł zmieniać się między sesjami — a to właśnie z niego budowany jest odcisk licencji. Był ustalany od nowa przy każdym wywołaniu i zapisywany bez oczekiwania na zapis, więc drugie wywołanie albo okno edytora zamknięte krótko po starcie mogło utworzyć nowy. Identyfikator, który się zmienia, to klucz aktywacyjny, który przestaje pasować; zawyżał też każdą liczbę liczoną na instalację. Teraz jest ustalany raz na sesję i zapisywany, zanim cokolwiek go użyje. Kompilacja 2.
0.2026.71 — Który plik śledzenia pokrył ten wiersz
2026-09-08
Dodano
- Przypisanie pochodzenia na poziomie wiersza. Przy więcej niż jednym wczytanym pliku śledzenia dymek z liczbą wykonań kończy się teraz słowami Pokryte przez: i listą raportów, które zapisały wykonanie w tym wierszu — a kliknięcie wiersza pliku śledzenia w widoku Coverage podświetla teraz wiersze, które on wniósł, w każdym otwartym edytorze, tak jak wcześniej podświetlało zmierzone przez niego pliki. To jedyne pytanie, na które potrafi odpowiedzieć scalony przebieg, a pojedynczy raport nie: dwa pliki śledzenia mierzące ten sam plik różnią się co do jego wierszy, a dotąd scalanie tę różnicę wygładzało i nigdy jej nie pokazywało. Scalanie nadal odbywa się plikami — najnowszy raport w całości wygrywa wspólny plik — więc pochodzenie wierszy indeksowane jest przed nim. Liczą się tylko wiersze pokryte: raport, który zapisał wiersz jako
0, nie pokrył go.
- Rekord
TN: w lcov jest wreszcie czytany. Plik śledzenia, który nazywa swój zestaw testów — TN:integration — pokazuje się jako coverage.info (integration) wszędzie tam, gdzie nazywane jest pochodzenie, a nazwa przetrwa eksport z powrotem do lcov, zamiast zostać zapisana pusta. Większość narzędzi pisze TN: pusty i nic się nie zmienia; te, które go wypełniają, to właśnie te, których pliki się scala, a wtedy nazwa jest jedynym, co mówi, który jest który.
fuciniCoverage.lineHighlight podbarwia same wiersze. off | uncovered | heatmap, domyślnie wyłączone: półprzezroczyste tło za każdym niepokrytym i częściowo pokrytym wierszem, a w trybie heatmap także za każdym wykonanym, tym cieplejsze, im częściej się wykonywał. Osobne ustawienie zamiast czwartej wartości editorGutter.mode, bo chce się ich w różnych parach: podbarwione luki przy czystym marginesie albo słupki bez koloru za kodem. Półprzezroczyste, bo leży pod tekstem, i podbarwia luki, a nie wiersze pokryte, z tego samego powodu co margines.
fuciniCoverage.overviewRuler sam decyduje o pasku na pasku przewijania. follow (domyślnie) działa jak dotąd: pasek tam, gdzie margines rysuje słupek niepokryty lub częściowy, i nigdy dla mapy cieplnej. uncovered rysuje go nawet przy wyłączonym editorGutter.mode — mapa luk pliku wzdłuż paska przewijania i nic obok kodu. off zachowuje słupki i usuwa pasek. Wcześniej linijka była sztywno związana z marginesem, więc tych dwóch kombinacji nie było.
Naprawiono
- Plik śledzenia, którego nie da się przeanalizować, mówi teraz, jako co go odczytano. „…nie jest poprawnie sformułowany” zostawiało czytającego z pytaniem, czy plik w ogóle rozpoznano jako format, o którym myśli — a dokument Cobertura odrzucony przez analizator VectorCAST to inny problem niż dokument naprawdę ucięty. Powiadomienie kończy się teraz zdaniem Odczytano go jako cobertura., gdy jakiś analizator przejął plik. Jeśli żaden go nie przejął, nic nie jest dodawane: „nie jest w formacie, który czyta to rozszerzenie” mówi to już w całości.
0.2026.70 — Komunikat o nieaktualnych danych znów pokazuje swoją ikonę
2026-09-08
Naprawiono
- Komunikat o nieaktualnych danych w dymku paska stanu znów pokazuje swoją ikonę zegara zamiast tekstu
$(history). Komunikat mówiący, że liczby pod nim opisują starszą wersję plików, nosi ten sam znak $(history) co sam pasek stanu. Na pasku stanu znak ten rysowany jest jako ikona zegara, ponieważ StatusBarItem.text sam podstawia ikony; dymek to MarkdownString, który musi się na to zgodzić przez supportThemeIcons, a nigdy tego nie robił — więc jedyne miejsce wyjaśniające, dlaczego pokryciu nie można ufać, zaczynało się od kawałka surowej składni. Dymek teraz to włącza.
0.2026.69 — Tryby marginesu, zdalne pliki śledzenia, obszary robocze wielokorzeniowe i pliki niezmierzone
2026-09-08
Dodano
- Własny margines edytora może teraz pokazywać niepokryte wiersze albo mapę cieplną liczby trafień. Domyślnie nadal pokazuje tylko ustalenia — paski MC/DC, trójkąty „od ostatniego przebiegu”, kropki edytowanych wierszy — a kolorowy widok całego pliku pozostaje w Annotated Source.
fuciniCoverage.editorGutter.mode włącza więcej: uncovered stawia pasek na każdym wierszu, który nigdy się nie wykonał, bursztynowy na każdym wierszu z gałęzią, której nigdy nie wzięto, i nic na wierszach pokrytych, więc zielona ściana nie zasłania trzech czerwonych; heatmap dodaje ciepły odcień na każdym wykonanym wierszu, tym gorętszy, im częściej się wykonał. Choose Editor Gutter Mode... przełącza między tymi trzema z palety lub z menu paska stanu. README twierdził dotąd wprost o „natywnych marginesach”; teraz mówi, co naprawdę tam jest. - Liczniki trafień w wierszu.
fuciniCoverage.hitCounts.inline dopisuje ×12 za każdym wierszem, w którym zaczyna się instrukcja, łącznie z ×0 — liczbę, która zawsze była w podpowiedzi, bez najeżdżania. Toggle Inline Hit Counts ją przełącza; menu paska stanu oferuje ją jako Pokaż lub Ukryj, zależnie od tego, co ma zastosowanie. ${env:NAME}, ${config:section.key}, ${userHome} i ${workspaceFolderBasename} w każdym ustawieniu ścieżki, obok ${workspaceFolder}, który już tam był. Zmienna, której rozszerzenie nie zna, zostaje tak, jak ją zapisano, więc literówka pojawia się w dzienniku wykrywania jako ścieżka, której szukano, zamiast zniknąć. - Wpis
coverageFile.paths może być adresem URL http(s)://. Artefakt jest pobierany do magazynu rozszerzenia przy każdym wczytaniu i stamtąd wczytywany; widok Coverage podaje adres URL, a nie ścieżkę pamięci podręcznej. Każde pobranie jest warunkowe (ETag / Last-Modified), więc ponowne pobranie niezmienionego artefaktu niczego nie ściąga, a gdy pobranie się nie powiedzie, wczytywana jest ostatnia pobrana kopia, a powód trafia do wyjścia. fuciniCoverage.remote.headers dodaje nagłówki Name: value z rozwiniętymi zmiennymi — Authorization: Bearer ${env:CI_TOKEN} trzyma token z dala od settings.json — a fuciniCoverage.remote.refreshMinutes pobiera ponownie według zegara. Dodaj #lcov.info (lub inną nazwę pliku) jako fragment adresu URL, gdy sam adres nie kończy się nazwą pliku, aby format był znany. - Wczytywanie i Generate Full HTML Report pokazują postęp i można je anulować. Wczytanie dziesięciu lub więcej plików śledzenia, albo 8 MB lub więcej takich plików, działa pod powiadomieniem o postępie z przyciskiem Anuluj, które podaje czytany plik i etap (odczyt, potem sprawdzanie źródeł); mniejsze tylko kręci paskiem stanu jak dotąd. Anulowanie zostawia poprzedni przebieg wczytany i mówi o tym. Raport HTML robi to samo dla każdej wyrenderowanej i zapisanej strony.
- Dwa kolejne powody do przeładowania. Bezwzględny wpis
coverageFile.paths poza obszarem roboczym — drzewo kompilacji obok checkoutu, katalog wyjściowy Bazela — jest teraz również odpytywany, więc plik, który pojawi się tam po otwarciu okna, zostaje wczytany, zamiast nigdy więcej nie być sprawdzany; obserwator widział dotąd wyłącznie obszar roboczy. A fuciniCoverage.watch.reloadAfterTasks wymienia zadania (label z tasks.json albo source: name, tak jak pokazuje je lista Run Task, np. npm: test), których zakończenie przeładowuje pokrycie, niezależnie od tego, czy watch.enabled jest włączone — dla kompilacji, za którymi obserwator nie nadąża: przebieg, który podmienia dowiązane symbolicznie drzewo wyjściowe, raport na udziale sieciowym, krok pokrycia, który dodatkowo przetwarza swój plik. - Obszary robocze wielokorzeniowe. Każdy folder obszaru roboczego jest teraz wykrywany na własnych warunkach:
coverageFile.defaultLocation, coverageFile.paths, pathRemap, ignore, watch.*, remote.*, badge.*, katalogi raportów, gitDiff.*, problems.perLine, editorGutter.mode i hitCounts.inline są czytane per folder, więc obowiązuje własny .vscode/settings.json folderu albo jego wpis w .code-workspace; ${workspaceFolder} oznacza własny folder wpisu; pliki śledzenia znalezione we wszystkich folderach scalają się w jeden przebieg, a widok Coverage grupuje pliki według folderu. ${workspaceRoot} w regule pathRemap próbuje najpierw własnego folderu pliku śledzenia, potem pozostałych. Wszystko, co potrzebuje jednego folderu — okna dialogowe plików, wyjście raportu i odznaki, metadane git, Run Tests with Coverage — bierze folder aktywnego edytora, a przy kilku folderach i bez edytora uruchomienie testów pyta, który. Folder dodany do obszaru roboczego lub z niego usunięty sam przeładowuje pokrycie. Wcześniej dwanaście miejsc brało pierwszy folder, a drugi korzeń dostawał złą bazę do wszystkiego. - Przebieg jest publikowany do własnego widoku Test Coverage VS Code. Przy
fuciniCoverage.testCoverage.publish (domyślnie włączone) każdy wczytany przebieg trafia też do natywnego panelu Test Coverage, jego procentów per plik w Eksploratorze i własnego przełącznika edytora „Show Inline Coverage” — wiersze, gałęzie i funkcje, ze szczegółami wczytywanymi na żądanie. Show in Test Coverage View publikuje aktywny przebieg i otwiera panel, cokolwiek mówi ustawienie; menu paska stanu oferuje to za quickActions.showTestCoverage. - Gdy pliki nie pasują, proponowana jest reguła przemapowania ścieżek. Najczęstsze „wczytało się, ale nic się nie podświetla” to plik śledzenia, którego ścieżki pochodzą z kontenera lub checkoutu CI (
/build/src/a.c, /home/runner/work/repo/repo/src/a.c, C:\agent\_work\1\s\src\a.c), podczas gdy obszar roboczy ma src/a.c. Gdy po wczytaniu zostają niedopasowane pliki, rozszerzenie wyszukuje ich nazwy w obszarze roboczym, wywodzi regułę prefiksu, która wyjaśnia ich najwięcej, zapisuje ją w dzienniku jako [FUCINI_REMAP_002], a wynik wczytania oferuje Apply Suggested Remap — jedno kliknięcie dopisuje regułę do fuciniCoverage.pathRemap i przeładowuje. Suggest Path Remap Rule uruchamia tę samą analizę na żądanie. Bez kliknięcia nic nie jest zapisywane. fuciniCoverage.ignore: pliki, które nigdy się nie liczą. Pliki dostarczone z zewnątrz, generowane lub firm trzecich (vendor/**, **/*.generated.ts, build/**) są usuwane z przebiegu przy wczytywaniu, więc widok Coverage, pasek stanu, progi, odznaki, CodeLens, historia i eksporty liczą bez nich; wynik wczytania mówi, ile pominięto, a wyjście je wymienia. Wzorce dopasowują się do ścieżki względem obszaru roboczego i do ścieżki bezwzględnej; wzorzec bez / pasuje do nazwy folderu lub pliku na dowolnej głębokości, jak w .gitignore. Dotyczy całych plików — wiersze wewnątrz pliku nadal wyklucza się własnymi znacznikami narzędzia. - Wpisy w Problems per wiersz, opcjonalnie.
fuciniCoverage.problems.perLine (off, uncovered lub uncoveredAndPartial; domyślnie wyłączone) stawia diagnostykę Information na każdym ciągłym bloku wierszy, które nigdy się nie wykonały — martwa funkcja o czterdziestu wierszach to jeden wpis, nie czterdzieści — a w drugim trybie na każdym wierszu, którego gałęzi nigdy nie wzięto. Tylko dla otwartych dokumentów, więc przebieg z dwoma tysiącami plików nie zaleje panelu; wpisy podążają za swoimi wierszami podczas edycji bufora i znikają, gdy dokument zostanie zamknięty. Wpis per plik za problems.enabled pozostaje bez zmian. - Odznaka pokrycia do README. Generate Coverage Badge zapisuje do obszaru roboczego SVG w stylu shields dla aktywnego przebiegu (
fuciniCoverage.badge.outputPath, domyślnie coverage-badge.svg), aby README osadził go przez , bez żadnej usługi hostowanej. badge.metric wybiera wiersze, gałęzie, MC/DC lub wynik ważony; kolor podąża za poziomami colorScale; badge.autoUpdate przepisuje ją po każdym wczytaniu. Odznaka SVG, którą Export Coverage Report już oferował, korzysta teraz z tego samego renderera. - Niezmierzone a niepokryte. Pliku, którego żaden test nigdy nie wczytał, w ogóle nie ma w pliku śledzenia, więc rozszerzenie zawsze odróżniało go od pliku zmierzonego z 0 trafień — i trzymało poza liczbami, przez co projekt, w którym połowa modułów nie ma testów, czyta się jako „92%”. Teraz to rozróżnienie widać: otwarcie takiego pliku stawia
not measured na pasku stanu, a fuciniCoverage.unmeasured.mode decyduje, co dzieje się poza tym. list dodaje do widoku Coverage grupę Unmeasured z każdym plikiem obszaru roboczego takiego rodzaju, jaki przebieg mierzył, a którego przebieg nie zawiera, zlicza je w wyniku wczytania, oznacza je ? w Eksploratorze, gdy odznaki są włączone, i pozwala threshold.unmeasuredFiles oblać Check Coverage Thresholds powyżej wybranej liczby. count idzie dalej: każdy taki plik dołącza do przebiegu jako 0% — jeden niepokryty wiersz na każdy wiersz kodu — więc pasek stanu, progi, odznaki, historia, eksporty i widok Test Coverage widzą uczciwą liczbę; plik jest wszędzie rysowany jako niezmierzony, nigdy jako „nie zgadza się już ze swoim pokryciem”. unmeasured.exclude trzyma z dala nagłówki i podobne pliki (domyślnie **/*.h, **/*.hpp, **/*.hh, **/*.inl, **/*.d.ts). Domyślnie wyłączone; stan na pasku stanu to jedyna zmiana, która jest zawsze włączona. - Widok Pokrycia pokazuje, co zrobiło scalanie. Od 0.2026.63 własne ponowne uruchomienie modułu wczytane na uruchomienie całego projektu zastępuje jego liczby dla plików modułu, a każdy wiersz podawał raport, z którego pochodzi — ale wiersz, którego liczby zastąpiły starszy raport, wyglądał dokładnie jak wiersz zmierzony przez jeden z kilku raportów, i nic nie mówiło, jak duża część raportu została zastąpiona. Teraz plakietka pliku śledzenia takiego wiersza ma obrys; każdy wiersz pliku śledzenia nad drzewem liczy, co scalanie zrobiło z jego plikami („42 pliki · 7 zastąpionych przez nowszy raport”, „7 plików · zastępuje 7 w starszych raportach”); a kliknięcie wiersza pliku śledzenia podświetla w pełnym drzewie zmierzone przez niego pliki, przygaszając resztę, aż do ponownego kliknięcia.
fuciniCoverage.coverageView.mergedMarks (domyślnie włączone) wyłącza obrys i podświetlenie; liczby zostają.
0.2026.68 — Stanowiska zespołowe proszą o kod zaproszenia
2026-09-07
Naprawiono
- Użytkownik Business lub Enterprise jest teraz proszony o swój kod zaproszenia, a nie o kod firmy. Od 2 września serwer licencji odrzuca współdzielony kod firmy dla stanowiska Business lub Enterprise: stanowisko zajęte tym kodem nie wskazywało nikogo, więc każde stanowisko zespołowe jest teraz powiązane z adresem, na który wysłano zaproszenie, a kodem, który je aktywuje, jest kod zaproszenia
FCI1… z tej wiadomości. Kwestionariusz nadal opisywał pole jako „Kod firmy”, podpowiadał, by poprosić o niego przełożonego, i pokazywał przykład FCB1… — odsyłając ludzi do wklejenia właśnie tego jedynego kodu, który już nie działa, a potem każąc im wpisać kod firmy, gdy zostawili pole puste. W planach zespołowych pole nazywa się teraz „Kod zaproszenia”, podpowiedź mówi, skąd pochodzi kod i że współdzielony kod firmy nie aktywuje stanowiska, przykład pokazuje postać FCI1…, a komunikat walidacji prosi o kod zaproszenia. Pro prosi o swój kod subskrypcji pod tą nazwą. Pro Plus pozostaje bez zmian: celowo zachowuje współdzielony kod. Wszystkie 17 języków interfejsu ma nowe brzmienie.
0.2026.67 — ${workspaceFolder} działa w obu ustawieniach ścieżek
2026-09-05
Naprawiono
${workspaceFolder} działa teraz w coverageFile.paths, tak jak zawsze działał w coverageFile.defaultLocation. Oba ustawienia leżą obok siebie i tylko jedno z nich dokumentowało zmienną, więc ludzie wpisywali ją w obu — a wpis zaczynający się od ${ nie jest bezwzględny, trafiał więc do globu wyszukiwania dosłownie, pod folderem bazowym, nic nie znajdował, a rozszerzenie zgłaszało brak pokrycia. Taki wpis jest teraz najpierw rozwijany, co czyni go ścieżką bezwzględną, i po prostu sprawdzany. W ustawieniu pozostaje w takiej postaci, w jakiej został zapisany, nie jest zapisywany drugi raz w innej formie, gdy ten sam plik zostanie wybrany, i sam znika z ustawienia, gdy zostanie odładowany z widoku Coverage.- O skonfigurowanym pliku śladu, którego nie ma, informuje teraz wyjście. Wpis ze złą ścieżką zawodził w jedyny sposób, którego nic nie zgłaszało: „nie znaleziono pokrycia”, nie do odróżnienia od projektu, który naprawdę go nie ma.
[FUCINI_DISCOVERY] wymienia teraz każdy wpis, dla którego nie znaleziono pliku, oraz ścieżkę, w której szukano — raz na wpis, a nie przy każdym przeładowaniu; wpis z symbolem wieloznacznym nie jest zgłaszany, bo może czekać, aż kompilacja coś zapisze.
0.2026.66 — Gałęzie, MC/DC i wynik w CodeLens funkcji
2026-08-29
Dodano
- CodeLens dla funkcji pokazuje teraz gałęzie, MC/DC i wynik złożony, a nie tylko wiersze i trafienia — „add: 92% pokryte (12/13 wierszy, 52 trafienia, wynik 88%, gałęzie 3/4 (75%), MC/DC 2/3 (66%))”. Każdy z nich jest pomijany dla danej funkcji, gdy plik pokrycia nie ma tam nic do zgłoszenia — kompilacja w czystym C bez danych o gałęziach albo taka bez instrumentacji
-fcoverage-mcdc — zamiast pokazywać mylące 0/0; wynik również pojawia się tylko obok co najmniej jednego z pozostałych dwóch, bo przy wierszach jako jedynej metryce jest z definicji tą samą liczbą, od której lens już się zaczyna.
- Podpowiedź plakietki pochodzenia mówi, jak dawno zapisano każdy plik pokrycia, a nie tylko podaje jego znacznik czasu — „Zmierzone przez module.info (2026-08-15 14:32 · 3 godziny temu), zastępując to, co mówił o nim lcov.info (2026-08-01 09:10).” Zaokrągla aż do „przed chwilą”; po 30 dniach pokazywana jest tylko data bezwzględna.
- Remis w mtime plików pokrycia nie jest już cichy. Dwa raporty lądujące w tym samym kroku kompilacji albo system plików, którego rozdzielczość mtime jest grubsza niż sekunda, mogą zgłosić identyczny znacznik czasu dla plików, które oba mierzą — wcześniej zwycięzcę rozstrzygała kolejność w
coverageFile.paths, a na ekranie nic tego nie tłumaczyło. Kanał wyjścia teraz to mówi: [FUCINI_MERGE_TIE] wymienia oba pliki pokrycia i liczbę plików, które dzielą.
- „Show What Changed Since Last Run” w menu
… wiersza pliku, gdy tylko istnieje poprzednie uruchomienie, z którym można porównać — ta sama różnica dla pliku, którą Compare with Last Run już liczy, wycelowana w ten jeden plik, o który pytano, a nie w całe drzewo. Plik, w którym nic się nie ruszyło, mówi to wprost, zamiast nie oferować niczego.
- Polecenie Tune Colour Scale: wypróbuj kolory i progi
colorScale.* na żywym widoku Coverage, zanim się na nie zdecydujesz. Każda zmiana trafia prosto do ustawienia — widok i tak odrysowuje się przy każdej zmianie colorScale/threshold, więc zapisanie wartości jest podglądem — a końcowe „Zachowaj” lub „Przywróć pierwotne wartości” zamyka pętlę.
- Luki w pokryciu dla poszczególnych plików w panelu Problems, jeden wpis na każdy wczytany plik źródłowy poniżej
threshold.statement, za nowym ustawieniem fuciniCoverage.problems.enabled (domyślnie wyłączone — domyślny próg instrukcji to 100). Każdy wpis streszcza, co jest niepokryte („62% wierszy pokrytych — 14 niepokrytych wierszy, 2 niepokryte funkcje”), i niesie szybką poprawkę, która otwiera zainstalowane rozszerzenie czatu (Copilot, Claude Code, …) z poleceniem napisania testu dla tej luki — diagnostyka na poziomie wiersza zalałaby Problems w prawdziwej bazie kodu, więc pozostaje to na poziomie pliku, na którym czytelnik naprawdę może coś zrobić.
Naprawiono
- Powód dla pliku brakującego, niezgodnego lub zweryfikowanego w widoku Coverage można teraz zaznaczyć i skopiować. Dotąd żył tylko w natywnej podpowiedzi
title wiersza, której — jako własnej podpowiedzi przeglądarki — nie da się zaznaczyć; kto chciał wkleić dokładny powód do zgłoszenia błędu, musiał go przepisać ręcznie. Najechanie pokazuje teraz ten sam tekst w prawdziwym, ostylowanym panelu, po którym można przeciągnąć jak po każdej innej treści strony. Podpowiedź zwykłego pliku (sama jego ścieżka) pozostaje bez zmian.
- Funkcja, której lista parametrów rozciąga się na kilka wierszy, nie jest już fałszywie zgłaszana jako przeniesiona.
detectMismatch pozwalał, by zapisany wiersz deklaracji różnił się od miejsca, w którym faktycznie znajduje się jej nazwa, o najwyżej dwa wiersze — dość na zwykłą rozbieżność między wierszem sygnatury, wierszem typu zwracanego i nawiasem otwierającym, ale nie na wielowierszową listę parametrów, która może je rozsunąć dowolnie daleko. void LOG_Emit(...) — siedem parametrów, po jednym w wierszu — zapisana przy swoim nawiasie otwierającym, w wierszu 163, była zgłaszana jako "LOG_Emit" is at line 3: najbliższe dopasowanie tekstowe, którym okazała się nazwa samej funkcji wspomniana w komentarzu nagłówkowym pliku, nigdzie w pobliżu wiersza 163 ani prawdziwej deklaracji w wierszu 156. Sprawdzenie przyjmuje teraz także nazwę znalezioną dalej wstecz, gdy każdy wiersz między nią a wierszem zapisanym czyta się jako jedną nieprzerwaną deklarację — bez pustego wiersza, bez wiersza kończącego poprzednią instrukcję lub blok — co lista parametrów spełnia zawsze, a naprawdę przeniesiona funkcja prawie nigdy. Tam, gdzie niezgodność jest wciąż prawdziwa, zgłaszany wiersz to teraz dopasowanie najbliższe zapisanemu, a nie zawsze pierwsze znalezione w pliku.
- Plakietka pochodzenia nie mówi już „+N”. Wczytanie własnego raportu modułu na wierzch szerszego uruchomienia oznaczało plakietkę pliku nazwą modułu plus liczbą innych plików pokrycia, które też go obejmowały — pomyślane jako „tyle zostało przegłosowanych”, czytało się jako „te raporty się zgadzają”, a z drzewa nie dało się poznać, który z n miała naprawdę na myśli. Plakietka wymienia teraz wyłącznie plik pokrycia, którego liczby są na ekranie; podpowiedź nadal wyjaśnia, co zostało przegłosowane i kiedy.
- Plakietka pochodzenia nie wypycha już nazwy pliku, obok której stoi, poza krawędź panelu. Szerokość plakietki była stała (
flex: none), więc gdy w wierszu brakło miejsca, nazwa pliku pochłaniała cały niedobór i skracała się pierwsza, choć z tych dwojga to plakietka jest mniej ważna. Plakietka oddaje teraz własną szerokość, zanim nazwa pliku straci choć jeden znak; procent i pasek, które i tak stoją wyżej niż nazwa pliku, pozostają nietknięte.
0.2026.65 — Ponowne uruchomienie modułu zastępuje to, co mówiło szersze uruchomienie
2026-08-15
Zmieniono
- Własne ponowne uruchomienie modułu zastępuje to, co mówiło o nim szersze uruchomienie, zamiast się do niego dodawać. Wczytanie raportu całego projektu, a potem na wierzch własnego raportu jednego modułu, sumowało dotąd ich liczby trafień dla każdego pliku, który oba dzieliły — ponowne uruchomienie samych testów tego modułu zawyżało liczby, które szersze, teraz już nieaktualne uruchomienie zdążyło zgłosić, zamiast je odświeżać. Plik pokrycia z najnowszym mtime na dysku wygrywa teraz bez reszty dla każdego pliku, który mierzy: instrukcje, gałęzie, deklaracje i zestawienia dla pliku (podsumowania gałęzi, MC/DC, funkcji, wywołań funkcji, obiektów i mutacji) pochodzą wszystkie wyłącznie z tego raportu, niezależnie od tego, gdzie któraś ze ścieżek stoi w
coverageFile.paths — ponowne uruchomienie modułu wygrywa, bo naprawdę jest nowsze, a nie dlatego, że akurat wczytuje się ostatnie. Plik pokrycia, który dla danego pliku nie zgłasza żadnych instrukcji — eksport kodu obiektowego z TRACE32, raport mutacji Stryker wczytany obok prawdziwego — nadal wnosi tylko to podsumowanie, które faktycznie niesie, zostawiając szczegóły wierszy/gałęzi wcześniejszego raportu nietknięte; ten przypadek się nie zmienia. Usuwa to też dawną wadę, przez którą zestawienie MC/DC (albo funkcji/wywołań funkcji/mutacji) dla pliku zmierzone przez dwa uruchomienia miało zsumowany mianownik razem z licznikiem, zaniżając prawdziwy procent. Podpowiedź plakietki pochodzenia mówi teraz „zastępując to, co mówił o nim _”, a nie „zsumowane”.
Naprawiono
- Długa nazwa pliku w widoku Coverage jest teraz skracana, zamiast się wylewać. Elementowi span z nazwą w wierszu brakowało
min-width: 0, jedynej deklaracji, która pozwala overflow/text-overflow: ellipsis elementu flex naprawdę zadziałać — bez niej długa nazwa zachowywała pełną szerokość, gdy panel wystarczająco się zwęził, wchodząc pod plakietkę pochodzenia, procent i pasek, które po niej następują.
0.2026.64 — Sortowanie widoku Coverage według wyniku
2026-08-01
Dodano
- Sortuj widok Coverage według wyniku, nie tylko według nazwy. Każdy wiersz niesie już wynik WHM i rozbicie na metryki; znalezienie najgorszego pliku w dużym drzewie oznaczało przeczesywanie w tym celu listy alfabetycznej. Lista rozwijana obok Zwiń wszystko / Rozwiń wszystko oferuje teraz Nazwa pliku, Wynik złożony, Wiersze, Gałęzie i MC/DC — każdy tryb poza Nazwa pliku przeplata foldery i pliki razem, od najgorszych według własnego procentu danej metryki, więc słabo przetestowany folder plasuje się dokładnie tak jak słabo przetestowany plik, zamiast być zgrupowany z dala od niego. Plik bez danych dla oglądanej metryki (powiedzmy format, który nigdy nie zgłasza gałęzi) sortuje się na sam dół, zamiast być czytany jako 0%. Wybór jest zapisywany do nowego ustawienia
fuciniCoverage.coverageView.sortBy w chwili dokonania, więc przetrwa przeładowanie okna, zamiast zawsze zaczynać od Nazwa pliku.
Naprawiono
- Wielowierszowa sygnatura funkcji nie jest już fałszywie oznaczana jako „przeniesiona”.
fnMap Istanbula daje funkcji dwa odwołania do wiersza — gdzie stoi jej nazwa i gdzie zaczyna się jej ciało — a parser wolał wiersz ciała dla sprawdzenia niezgodności, które później szuka nazwy w tekście źródłowym. Dla każdej funkcji, której lista parametrów rozciąga się na więcej niż dwa wiersze (rutyna w bazie kodu zawijanej na 100 kolumnach), prawdziwy wiersz nazwy leżał za daleko od zapisanego, a plik przygasał w widoku Coverage z fałszywym ostrzeżeniem „nie odpowiada już swojemu pokryciu”. Parser woli teraz wiersz samej nazwy, którego sprawdzenie niezgodności zawsze szukało.
0.2026.63 — Każdy wiersz podaje swój plik pokrycia
2026-07-20
Dodano
- Każdy wiersz mówi, który plik pokrycia go zmierzył. Wczytanie raportu jednego modułu na wierzch pokrycia całego projektu to te same pliki zmierzone dwa razy, a drzewo nie mówiło, który raport czyta dany wiersz. Gdy wczytano więcej niż jeden plik, każdy wiersz niesie teraz nazwę raportu, który go zmierzył — ostatnio wczytanego, jeśli było ich kilka — z
+1 za każdy pozostały i podpowiedzią, która je wymienia. Scalanie sumuje ich trafienia, zamiast wybierać zwycięzcę, i podpowiedź to mówi. Przy jednym pliku nic nie jest rysowane, bo nie byłoby czego odróżniać.
Zmieniono
- Własna strona rozszerzenia wymienia każde ustawienie wraz z jego rzeczywistą wartością domyślną. Dwadzieścia ustawień nie miało w ogóle wiersza — język, trzy progi, jedna waga i piętnaście przełączników szybkich akcji — a wiersz telemetrii twierdził, że jest ona domyślnie włączona, choć od dawna jest wyłączona. Test porównuje teraz stronę z manifestem, wraz z wartościami domyślnymi.
Naprawiono
- Ponowne sprawdzanie źródeł objętych
files.watcherExclude, dodane w poprzednim wydaniu, słucha teraz staleWarning.enabled jak reszta tego sprawdzenia, a nie własnej nazwy ustawienia.
0.2026.62 — Eksplorator zostawiony w spokoju, wyciszone źródła sprawdzane ponownie
2026-07-06
Zmieniono
- Eksplorator zostaje w spokoju. Plakietki pokrycia obok plików w Eksploratorze są domyślnie wyłączone. Ta kolumna należy do tego, kto z niej korzysta — VS Code umieszcza tam własne M i U gita, a mieści się tylko jedna plakietka — a widok Pokrycie wymienia te same pliki z tymi samymi liczbami, w miejscu, które dla nich istnieje.
explorerBadges.enabled przywraca je bez zmian.
Naprawiono
- Źródło objęte
files.watcherExclude też jest sprawdzane ponownie. Bieżącą zgodność pliku z jego pokryciem napędzają zapisy i obserwator systemu plików, a ten milczy o wszystkim, co wykluczone — przede wszystkim o generowanych źródłach w build/, gdzie nieaktualne oznaczenie najtrudniej zauważyć. Te pliki są teraz odpytywane w tym samym dwusekundowym takcie co pliki pokrycia i czytane ponownie tylko wtedy, gdy naprawdę się zmieniły. Powyżej dwustu wyjście mówi o tym zamiast zużywać takt.
0.2026.61 — Jedno pytanie o program uruchamiający testy, a nie jedno na każde uruchomienie
2026-06-09
Dodano
- O program uruchamiający testy pyta się raz, a nie przy każdym uruchomieniu. Obszar roboczy z więcej niż jednym rozpoznanym programem — na przykład konfiguracją jest i plikiem
go.mod — stawiał listę wyboru przed każdym Run Tests with Coverage, każąc naciskać klawisz za decyzję już podjętą. Odpowiedź jest teraz zapamiętywana dla obszaru roboczego, a monit to mówi. Forget the Test Runner przywraca pytanie, a zapamiętany program, którego obszar roboczy już nie ma, jest pomijany zamiast uruchamiany.
Zmieniono
- Własna strona rozszerzenia wymienia każde polecenie. Czternaście z trzydziestu czterech wypadło z jej tabeli — opisane tutaj i w przewodniku, ale nie na stronie, którą czyta się przed instalacją. Teraz są wszystkie, a test tego pilnuje.
0.2026.60 · build 3 — Cofnięcie znów usuwa kropki
2026-06-01
Naprawiono
- Cofnięcie znów usuwa kropki z edytowanych wierszy. Bufor edytowany po uruchomieniu pokazuje szare kropki na przepisanych wierszach, a pokrycie się z nich wycofuje. Cofnięcie tych zmian zostawiało kropki na miejscu: liczyła się każda zmiana, także ta, która przywracała tekst. Teraz zapamiętywane jest to, co bufor zawierał, zanim ktokolwiek zaczął pisać, i gdy tylko zawiera to znowu, kropki znikają, a liczby znów go dotyczą.
- Numery wydania są sprawdzane wzajemnie. Manifest, górny wpis dziennika zmian i etykieta wydania niosą wersję i numer kompilacji, wszystkie trzy wpisywane ręcznie, i już się rozjechały. Zestaw testów porównuje je teraz i sprawdza, że wpisy idą od najnowszego, każdy z prawdziwą datą.
0.2026.59 — Wyładowanie, które trwa
2026-05-12
Zmieniono
- Wyładowany plik pokrycia pozostaje wyładowany. Zdjęcie pliku z listy w widoku Pokrycie trwało dokładnie tyle, co okno: bez konfiguracji wykrywanie wraca do znanych nazw i następnego ranka znów znajdowało
lcov.info, a jedynym sposobem, by powiedzieć inaczej, było skonfigurowanie ścieżki po to, by jedną wykluczyć. Decyzja jest teraz zapamiętywana dla obszaru roboczego. Cofa ją ponowny wybór pliku albo wpisanie go do coverageFile.paths — pliku, który ustawienie wymienia, nigdy się nie wstrzymuje, więc nic nie zniknie bez czyjegoś słowa.
Naprawiono
- Szybsze odrysowywanie edytowanego bufora. Lista przepisanych wierszy była przy każdym odrysowaniu liczona od nowa ze wszystkich zapisanych zmian, więc długi plik edytowany całe popołudnie płacił liczbą wierszy razy liczbą zmian za odpowiedź, która od ostatniego naciśnięcia klawisza się nie zmieniła. Teraz liczy się ją raz na naciśnięcie.
0.2026.58 · build 2 — Uruchomienie testów zapamiętuje swój plik pokrycia
2026-05-01
Zmieniono
- Uruchomienie testów zapamiętuje swój plik pokrycia, tak jak wybór ręczny. Run Tests with Coverage wczytywał to, co zapisało uruchomienie, a potem pytał, czy dodać to do
coverageFile.paths. Plik wybrany ręcznie zapisuje się tam sam od 0.2026.56, a uruchomienie testów to ten sam czyn inną drogą, więc teraz zapisuje go tak samo. Obydwoma rządzi jedno ustawienie, coverageFile.rememberPicks; wiersz pliku w widoku Pokrycie to miejsce, w którym jedno i drugie znów schodzi z listy.
Naprawiono
- Zegary w tle zatrzymują się razem z rozszerzeniem. Obserwator pliku pokrycia był zwalniany wraz z oknem, ale stojące za nim dwusekundowe odpytywanie i każde oczekujące sprawdzenie źródła to zwykłe zegary, których nic nie zwalnia. Wyłączenie rozszerzenia albo przeładowanie okna z wyłączonym rozszerzeniem zostawiało je działające i czytające obszar roboczy, do którego rozszerzenie nie miało już żadnego interesu.
0.2026.57 · build 4 — Opisany podgląd na żywo, rysowane flagi, każdy format w oknie wyboru
2026-04-24
Dodano
- Podgląd na żywo mówi, co pokazuje. Podgląd w panelu ustawień zaczyna się teraz od Przebieg: coverage/lcov.info · 12 plików, a gdy aktywny edytor pokazuje plik objęty przebiegiem — od Aktywny plik: src/a.c z własnym werdyktem tego pliku pod werdyktem przebiegu. Podąża za edytorem i każdym wczytaniem, według tego, co zawiera formularz — łącznie z niezapisanymi zmianami. Gdy panel jest z przodu, kliknięcie w widoku Pokrycie przełącza podgląd na ten plik zamiast go otwierać.
- Okno wyboru nazywa każdy format. Najpierw Wszystkie formaty pokrycia, potem LCOV; JSON (llvm-cov, Istanbul/nyc, coverage.py, SimpleCov, Coveralls, gcov, xccov, Stryker); XML (Cobertura, JaCoCo, Clover, OpenCover, GNATcoverage, Bullseye, SonarQube, VectorCAST, TRACE32, EMMA, UCIS/UCDB, NCover, dotCover, PIT); profil pokrycia Go; listing gcov i Testwell CTC++ — a
.lcov, .gcov, .txt i .coveragexml nie są już wyszarzone.
Zmieniono
- Podpowiedzi paska stanu noszą skalę kolorów. Paski metryk w podpowiedziach przebiegu i pliku przyjmują trzy kolory z
colorScale.*, stopniowane według własnego progu każdej metryki, gdy jest ustawiony, a w przeciwnym razie według punktów skali; plakietki werdyktu zachowują stałe kolory stanu.
- Rysowane flagi w ustawieniu języka. Emoji flag z 0.2026.56 wyświetlają się w Windows jako dwie gołe litery. Lista nazywa teraz każdy język jego własną nazwą — Nederlands (nl) — a pod nią rząd małych rysowanych flag, które wybierają na liście.
0.2026.56 · build 3 — Wybory są zapamiętywane, pliki śladu w widoku Pokrycie, flagi w ustawieniu języka
2026-04-08
Dodano
- Wybór jest zapamiętywany. Plik wybrany poleceniem Pick Coverage File żył tylko w oknie, w którym go wybrano. Teraz sam trafia do
coverageFile.paths w ustawieniach obszaru roboczego — względem folderu bazowego, gdy leży w nim, w przeciwnym razie bezwzględnie — więc następne okno go wczytuje, a obserwator przeładowuje. coverageFile.rememberPicks (domyślnie włączone) zachowuje dawne zachowanie dla chętnych. Wpis bezwzględny w tym ustawieniu wskazuje teraz jeden plik, gdziekolwiek jest.
- Pliki śladu w widoku Pokrycie. Nad drzewem po jednym wierszu na wczytany plik śladu z liczbą plików i przyciskiem wyładowania, który usuwa go z przebiegu i z ustawień; przycisk Wybierz… obok dodaje nowy. Wyładowanie ostatniego pliku śladu czyści przebieg.
- Flagi w ustawieniu języka. Lista języków w panelu ustawień pokazywała gołe kody; każda pozycja ma teraz flagę i nazwę języka w nim samym — 🇳🇱 Nederlands (nl), 🇯🇵 日本語 (ja), 🌐 Automatycznie.
0.2026.55 — Ostatni wiersz pliku PHP nie jest pokryciem poza końcem
2026-03-27
Naprawiono
- Ostatni wiersz pliku PHP nie liczy się już jako pokrycie poza końcem pliku. Xdebug i PCOV zapisują niejawny return końca pliku w wierszu po ostatnim znaku nowej linii, więc php-code-coverage wpisuje trafienie w „wierszu 252” pliku o 251 wierszach — a sprawdzanie niezgodności nazywało to sprzecznością w każdym pliku PHP z końcowym znakiem nowej linii. Jeden wiersz za końcowym znakiem nowej linii jest teraz dozwolony; odwołanie dalej, lub poza plik bez końcowego znaku nowej linii, pozostaje sprzecznością, jaką było.
0.2026.54 · build 2 — Wiersz okresu próbnego w What Community Includes
2026-03-24
Dodano
- Wiersz okresu próbnego w What Community Includes, w edycji Community. Ta kompilacja nigdy nie miała okresu próbnego, więc jej lista zaczyna się teraz od Rozpocznij 14-dniowy okres próbny Pro…, który otwiera wpis Pro; aktywacja kompilacji Pro proponuje potem usunięcie kompilacji Community z drogi. Community pozostaje bezpłatne, cokolwiek zostanie zdecydowane.
0.2026.53 — Show Worst-Covered Folders
2026-03-03
Dodano
- Show Worst-Covered Folders. Odpowiedź na poziomie folderów na Show Worst-Covered Files: każdy folder uszeregowany według pokrycia wszystkiego poniżej, od najgorszego, z tego samego indeksu, z którego malowane są odznaki Eksploratora; wybór pokazuje folder w Eksploratorze. W menu paska stanu z
quickActions.worstCoveredFolders.
0.2026.52 — Kontrola progów w panelu Problemy
2026-01-23
Dodano
- Kontrola progów w panelu Problemy. Z włączonym
compliance.diagnostics każda nieosiągnięta metryka threshold.* to jeden błąd w Problemach, na pliku śladu, który jej nie spełnił, odświeżany przy każdym wczytaniu i przez Check Coverage Thresholds, czyszczony, gdy kontrola przechodzi. Domyślnie wyłączone, bo dostarczany próg instrukcji to 100.
Zmieniono
- Opis
watch.enabled nie obiecuje już pytania. Wciąż mówił, że edycja bezpłatna jest pytana przed przeładowaniem — prawda do 0.2026.48, od tamtej pory nie. Przepisany we wszystkich 18 językach.
0.2026.51 · build 2 — Run Tests with Coverage
2025-12-08
Dodano
- Run Tests with Coverage. Rozpoznaje vitest, jest, pytest, go, cargo, dotnet, maven, gradle, phpunit lub ctest po korzeniu obszaru roboczego, uruchamia go z włączonym pokryciem w zadaniu terminala, wczytuje to, co zapisał, niezależnie od wyniku testów, i raz proponuje dodanie tej ścieżki do
coverageFile.paths, aby odtąd wczytywaniem zajmował się obserwator. Kilka programów uruchamiających oferowanych jest do wyboru; żaden nie odsyła do przepisów.
0.2026.50 — Pokrycie podąża za tekstem w edytowanym buforze
2025-10-23
Dodano
- Pokrycie podąża za tekstem w edytowanym buforze. Edycje każdego otwartego bufora od wczytania przebiegu są zapamiętywane, a każda powierzchnia czytająca numery wierszy przebiegu — liczba trafień po najechaniu, pasek MC/DC, trójkąt „od ostatniego przebiegu”, CodeLens, Next Uncovered — czyta przez nie: oznaczenie przesuwa się ze swoim wierszem i znika z wiersza przepisanego, gdzie mała szara kropka mówi dlaczego.
dirtyMarks.enabled wyłącza kropki.
0.2026.49 — Od ostatniego przebiegu, na marginesie
2025-09-26
Dodano
- Od ostatniego przebiegu, na marginesie. Każdy wiersz wykonany w poprzednim przebiegu, a nie w tym, ma czerwony trójkąt na marginesie edytora, każdy wiersz, który poszedł w drugą stronę — zielony, każdy z paskiem na linijce przeglądu i liczbą trafień po najechaniu. Wiersze bez zmian nie pokazują nic.
sinceLastRun.enabled to wyłącza.
Zmieniono
- Punkt odniesienia „ostatni przebieg” przetrwa ponowne uruchomienie. Z włączonym
history.enabled najnowszy przebieg z historii przejmuje tę rolę przy pierwszym wczytaniu okna, więc kompilacja zakończona przed otwarciem okna nadal pokazuje, co zmieniła — na marginesie i w Compare with Last Run.
0.2026.48 · build 6 — Samoczynne przeładowanie wszędzie, oznaczenie podąża za plikiem, dokładna różnica po najechaniu
2025-09-19
Dodano
- Werdykt o pliku pozostaje aktualny po wczytaniu. Plik był sprawdzany względem swojego pokrycia raz, przy wczytaniu pliku śladu, i nigdy więcej: edytuj go całe popołudnie, a marginesy dalej malowały liczby o wersji, która już nie istniała. Teraz zapis w edytorze od razu sprawdza ten plik ponownie, a zmiana spoza edytora —
git checkout, formater, generator — sprawdza go ponownie z dysku chwilę później. Plik, który zaczyna przeczyć swojemu przebiegowi, dostaje oznaczenie; checkout przywracający zmierzoną wersję je usuwa.
- Dokładna różnica, po najechaniu. Tam, gdzie plik nie zgadza się już ze swoim pokryciem, widok Pokrycie i podpowiedź w Eksploratorze mówią dokładnie, co to udowodniło: wiersz w obecnym brzmieniu wobec tego, co zapisał raport, gdy plik śladu zachował tekst; wiersz i nieudana suma kontrolna, gdy zachował skrót; pokrycie poza końcem pliku; funkcja, której nie ma już tam, gdzie umieszcza ją raport. Ten sam szczegół trafia do kanału wyjścia, po jednym wierszu na plik, dokąd prowadzi Pokaż które w wyniku wczytania.
- Przełącznik odznak w Eksploratorze.
explorerBadges.enabled (domyślnie włączone) ukrywa wynik, ✓ i ⚠ obok każdego objętego pliku w Eksploratorze, a wraz z nimi podpowiedź z podziałem na metryki. Marginesy, pasek stanu i widok Pokrycie pozostają bez zmian.
Zmieniono
- Każda edycja przeładowuje samoczynnie, gdy zmieni się plik śladu. Od 2026-09-02 edycja bezpłatna zatrzymywała się na pytaniu wykryto nowe pokrycie — wczytać?, podczas gdy płatne licencje przeładowywały po cichu. Kompilacja się kończy, liczby są nowe, a kto włączył obserwowanie, już odpowiedział na to pytanie — więc pytanie zniknęło w każdej edycji, a wraz z nim komunikat, który je tłumaczył.
- Wczytania, które produkt wykonuje sam, nie liczą się już do dziennego limitu edycji bezpłatnej. Przeładowanie przez obserwatora lub wykrycie przy starcie nie jest wczytaniem, o które ktoś prosił; ich liczenie zużyłoby pulę instalacji Community w jeden poranek testów, a potem zostawiło na ekranie stary przebieg bez niczego, co by o tym mówiło. Limit mierzy teraz tylko polecenie i wybór pliku.
- Sama zmieniona sygnatura czasowa nie oznacza już pliku. Ostrzeżenie N plik(ów) zmieniono od tego przebiegu brało się z mtime każdego źródła, a
git pull lub formater zmienia każdy mtime, nie zmieniając tego, co zmierzono. Zniknęło, wraz ze swoim oznaczeniem na pasku stanu. Plik nazywany jest teraz zmienionym tylko wtedy, gdy jego zawartość przeczy przebiegowi, a pasek stanu, wynik wczytania i nowy wiersz wyjścia FUCINI_MISMATCH_001 czytają właśnie to. staleWarning.enabled zachowuje nazwę i opisuje teraz dokładnie sprawdzanie zawartości.
- Obserwowanie folderu pod
files.watcherExclude jest zgłaszane w wyjściu. Wyjście kompilacji to pierwsza rzecz, jaką wyklucza się z obserwatora VS Code, po czym nowy przebieg zauważa już tylko odpytywanie co 2 s. Kanał wyjścia podaje teraz folder i wzorzec przy starcie obserwatora.
0.2026.47 · build 2 — Niedopasowane ścieżki na ekranie, wskazówka przy pierwszym uruchomieniu, dwa klawisze więcej
2025-08-09
Dodano
- Wskazówka przy pierwszym uruchomieniu dla obszaru roboczego bez niczego do wczytania. Obserwacja jest domyślnie włączona, a wczytanie przy starcie jest ciche, więc świeża instalacja w projekcie bez pliku śladu nie mówiła nic. Pierwsze ciche wczytanie, które nic nie znajdzie, teraz to mówi — raz, na zawsze — wraz z dwiema rzeczami wartymi zrobienia: wybrać plik pokrycia ręcznie albo otworzyć przepisy, jak wytworzyć go swoim zestawem narzędzi. Wczytanie uruchomione ręcznie zachowuje własny komunikat.
- Klawisze dla Toggle Annotated Source i Load Coverage.
Alt+A przełącza aktywną kartę między źródłem a jego adnotowanym widokiem; Alt+Shift+R ponownie wyszukuje i wczytuje pokrycie (Ctrl+Alt+A / Ctrl+Alt+R w macOS). Do zmiany jak dwa z 0.2026.45.
Zmieniono
- Ścieżki niepasujące do niczego w obszarze roboczym są liczone na ekranie. Ścieżka z pliku śladu, która nie odpowiada żadnemu plikowi obszaru roboczego, wczytuje się i nigdy nie podświetla — najczęstsze „zadziałało, ale nic nie widać”, jakie istnieje — a dotąd jedynym śladem był wiersz
FUCINI_REMAP_001 w kanale wyjściowym, z regułą pathRemap, która by to naprawiła, nieprzeczytany. Wynik wczytania teraz je liczy, z przyciskiem Które? dla nazw i proponowanej reguły oraz Otwórz ustawienie pathRemap dla miejsca, w którym ją wpisać. - Wybór pliku w menu paska stanu wymienia formaty, które czyta. Jego opis wciąż wymieniał pięć formatów z pierwszego wydania; teraz mówi o dwudziestu pięciu, od lcov, Cobertura i JaCoCo po gcov, llvm-cov, TRACE32 i raporty mutacji.
0.2026.46 — Wyjście z konfliktu edycji i cichszy limit
2025-08-06
Zmieniono
- Zainstalowane obie edycje: dwa przyciski zamiast instrukcji. Gdy Pro i Community są obecne razem, żadna nie może się aktywować — definiują te same polecenia i widoki — a komunikat o tym kończył się wskazówkami do widoku Rozszerzenia. Oba środki zaradcze to po jednym poleceniu, więc są teraz przyciskami: Zachowaj to odinstalowuje drugą edycję i proponuje przeładowanie; Pokaż oba w Rozszerzeniach otwiera widok Rozszerzenia dokładnie na tych dwóch. Jeśli odinstalowanie się nie powiedzie, przeładowanie i tak jest proponowane — to ono rozstrzyga, która edycja działa.
- Limit użycia jest ogłaszany w całości raz, potem tylko na pasku stanu. Pierwsze osiągnięcie limitu Community zasługuje na pełną odpowiedź — liczby, plan, odblokowanie przez telemetrię, listę tego, co zawiera poziom. Piąte, dziesięć minut później, nie. W ramach sesji kolejne osiągnięcia tego samego limitu wyświetlają ośmiosekundowy wiersz na pasku stanu i niczego nie przerywają. Wprowadzenie klucza zaczyna od nowa, bo nowa licencja to nowy zestaw limitów.
0.2026.45 — Klawisze dla Next / Previous Uncovered
2025-07-26
Dodano
- Next / Previous Uncovered mają klawisze. To dwa polecenia naciskane raz za razem podczas czytania pliku, a dotąd każde naciśnięcie oznaczało otwarcie palety poleceń i wpisanie nazwy.
Alt+N przechodzi do następnego niepokrytego zakresu, a Alt+P do poprzedniego (Ctrl+Alt+N / Ctrl+Alt+P w macOS, gdzie Option wpisuje znaki). Oba działają tylko w aktywnym edytorze tekstu i można je zmienić w Keyboard Shortcuts jak każde inne domyślne.
0.2026.44 · build 3 — Limity darmowego poziomu, na jednej liście
2025-07-24
Dodano
- Co zawiera Community, jako jedna lista. Darmowy poziom ogranicza osiem akcji i wstrzymuje dwanaście funkcji, a każda z tych decyzji była egzekwowana przy własnych drzwiach — więc jedynym sposobem poznania kształtu poziomu było wpadanie po kolei na każdą ścianę, w środku pracy. Nowe polecenie, What Community Includes, pokazuje wszystko naraz: każdą ograniczoną akcję z tym, ile dnia lub miesiąca już zużyto, każdą wstrzymaną funkcję z nazwy i dwa sposoby zniesienia tego — płatny plan albo odblokowanie przez telemetrię.
- Oferowane wszędzie tam, gdzie pojawia się pytanie. Pozycja w menu paska stanu, przycisk w banerze licencji widoku Coverage i przycisk w dwóch komunikatach, które instalacja Community napotyka pod ścianą — osiągnięto limit użycia i ta akcja nie jest objęta. Wiersze pochodzą z tego samego zestawu uprawnień, który egzekwują bramki, więc to, co mówi lista, jest tym, co się stanie.
Zmieniono
- Tryb obserwacji mówi, co zrobi na darmowym poziomie. Pozycja paska stanu obiecywała wszystkim „automatyczne przeładowanie pokrycia”, a w Community to obietnica, której obserwator nie dotrzymuje — zauważa i pyta. Pozycja teraz tak mówi, a polecenie nosi tytuł Toggle Tracefile Watch, bo „Toggle Watch” nigdy nie mówiło, co jest obserwowane. Samo zachowanie jest bez zmian.
0.2026.43 · build 3 — Nieudane wczytanie mówi dlaczego, a ukryte pliki są liczone
2025-06-25
Zmieniono
- Plik śladu, który się nie wczytuje, mówi teraz dlaczego i co spróbować. Każde niepowodzenie dawało to samo powiadomienie — „no coverage could be parsed. See output.” — z przyczyną o kanał dalej jako kod i komunikat parsera. Powiadomienie zaczyna się teraz od pliku i sortuje odmowę według tego, czym była: nie w formacie, który to rozszerzenie odczytuje, niepoprawnie sformułowany (zwykle kompilacja wciąż go zapisywała), poprawny, ale niczego nie rejestruje (przebieg nie wykonał zinstrumentowanego kodu) albo nie udało się odczytać. Słowa samego parsera idą razem, kilka plików jest liczonych, a kanał wyjściowy jest oferowany za przyciskiem Pokaż dane wyjściowe zamiast otwierany na siłę.
- Pliki, które plik śladu wymienia, ale w których nie ma czego mierzyć, są teraz liczone na ekranie. Nagłówek zawierający same deklaracje zawsze pozostawał poza widokiem Coverage zamiast dostawać 100% z 0 na 0 — a jego nazwa trafiała do kanału wyjściowego i nigdzie indziej. Wynik wczytania mówi teraz N plików bez niczego do zinstrumentowania nie jest pokazywanych, z przyciskiem Które? otwierającym kanał z nazwami.
0.2025.42 · build 3 — NCover i dotCover, pokrycie .NET bez miejsca docelowego
2025-06-08
Dodano
- NCover i JetBrains dotCover. Cobertura z Coverlet i OpenCover były tu już czytane, co obejmuje większość nowej pracy w .NET i nic ze starszego rodzaju. Kompilacja wciąż zapisująca
Coverage.xml NCovera, albo firma mierząca dotCoverem, miała na dysku pokrycie, którego to rozszerzenie nie mogło otworzyć. Żaden z formatów nie potrzebuje konwertera: oba już niosą nazwy plików i numery wierszy. - Wykluczony punkt NCover jest pomijany, a nie liczony jako niewykonany.
excluded="true" oznacza kod celowo wyjęty z pomiaru — składową z [ExcludeFromCodeCoverage] albo filtr NCoverExplorera. Liczenie go jako niepokrytego sprawiłoby, że wykluczenie obniżałoby liczbę, którą miało poprawić. - dotCover wymaga
/ReportType=DetailedXML. Jego drugi raport XML to zbiorcze zestawienie bez żadnego numeru wiersza; taki raport jest rozpoznawany i odrzucany ze wskazaniem flagi, która to naprawia, zamiast zawodzić jako nieznany format. dotCover zapisuje tylko tak/nie na instrukcję, nigdy liczbę odwiedzin, więc pokryta instrukcja daje jedno trafienie.
0.2025.41 · build 4 — Testowanie mutacyjne: PIT i Stryker
2025-05-28
Dodano
- Testowanie mutacyjne. Pokrycie mówi, że wiersz się wykonał; wynik mutacji mówi, że coś zawiodło, gdy ten wiersz zmieniono. Zestaw testów może wykonać każdy wiersz pliku i nie wykryć żadnej z wstrzykniętych usterek, a żadna liczba pokrycia tego nie powie. PIT obejmuje Javę, Kotlin i Scalę; Stryker obejmuje JavaScript, TypeScript, C# i Scalę.
- Nigdy nie jest uśredniany z pokryciem. Mieszanie „czy ten wiersz się wykonał” z „czy coś to zauważyło, gdy go zmieniłem” nie odpowiada na żadne z tych pytań, więc nie ma żadnej wagi w wyniku złożonym i jest bramkowany osobno przez
fuciniCoverage.threshold.mutation — domyślnie 0, bo wynik mutacji to cel do podnoszenia, a nie poprzeczka do przeskoczenia pierwszego dnia. - Mutant, który nigdy nie dostał uczciwego przebiegu, liczy się w żadnej z dwóch połówek.
NON_VIABLE w PIT oraz CompileError i Ignored w Strykerze to mutacje, których narzędzie nie mogło wykonać; liczenie ich jako niewykrytych karałoby zestaw testów za usterkę, której nigdy mu nie zaproponowano.
0.2025.40 — Tekstowy listing gcov, dla kompilatorów starszych niż GCC 9
2025-05-16
Dodano
- Adnotowany listing
.gcov. gcov --json-format pojawił się w GCC 9, a wbudowane kompilatory skrośne są często dużo starsze; dotąd odpowiedzią było najpierw zainstalować lcov lub gcovr. Licznik wykonań ma pięć zapisów, a tylko dwa z nich to liczby, a adnotacje branch/call/function należą do sąsiedniego wiersza, a nie własnego — to wszystko jest teraz odczytywane poprawnie. - Adnotacje wywołań stają się pokryciem miejsc wywołania.
call N returned X% to dokładnie ta miara wywołań funkcji dodana w 0.2025.38, którą ten format niósł na długo zanim było tu miejsce, by ją umieścić.
0.2025.39 · build 2 — Pokrycie kodu obiektowego, a wraz z nim asembler
2025-04-27
Dodano
- Pokrycie kodu obiektowego — jaka część zbudowanego pliku binarnego faktycznie się wykonała. Jedyna miara tutaj, która w ogóle nie jest mierzona ze źródeł: pochodzi z debuggera obserwującego strumień instrukcji na prawdziwym celu, bez żadnego wpływu sondy na czasy. To także szczera odpowiedź na pytanie "czy to obejmuje asembler?" — ręcznie pisany asembler nigdy nie jest instrumentowany, a żadna inna miara tutaj do niego nie sięga.
- To wymaganie, a nie kolejna waga. Pokrycie kodu obiektowego obejmuje pokrycie instrukcji — 100% tutaj oznacza 100% tam, ale nie odwrotnie — więc nie ma żadnej wagi w wyniku złożonym i zamiast tego jest bramkowane progiem, dokładnie tak, jak wymaga tego DO-178C poziomu A oprócz MC/DC.
- Luka jest produktem. Przebieg ze 100% pokryciem wierszy i mniejszym niż 100% pokryciem kodu obiektowego wskazał dokładnie ten wygenerowany przez kompilator kod, za którym nie stoi Twoje źródło; karta zgodności mówi "312 bajtów nigdy nie wykonano, przy 100% pokryciu wierszy", zamiast ukrywać to jako "94%". Odwrotny przypadek — cały plik binarny zgłoszony jako wykonany, choć jego źródło nie — zgłaszany jest jako sprzeczność, a nie niski wynik.
0.2025.38 · build 2 — Pokrycie wywołań funkcji, a VectorCAST i TRACE32 kompletne
2025-04-01
Dodano
- Pokrycie wywołań funkcji — czy każde miejsce wywołania zostało wykonane. Inne pytanie niż pokrycie funkcji: funkcja wywołana raz z jednego z trzech miejsc wywołania jest kompletna pod względem Funkcji, a tutaj kompletna w jednej trzeciej. VectorCAST, TRACE32 i Cantata wszystkie to zgłaszały, gdy ten model nie miał gdzie umieścić liczby.
- To dopełnia VectorCAST i TRACE32. Wcześniejsze wydania celowo odmawiały zwinięcia tych danych w pokrycie gałęzi, bo zawyżanie procentu gałęzi zawyża liczbę, która trafia do audytu. Oba formaty teraz wczytują to, co zawsze wysyłały.
Zmieniono
- Brama zgodności i wynik ważony znają teraz siedem miar, nie sześć — dwa nowe ustawienia,
fuciniCoverage.whmWeights.functionCalls i fuciniCoverage.threshold.functionCalls, z opisami we wszystkich 17 językach.
0.2025.37 — Pokrycie funkcji jako liczba, nie tylko jako miejsce
2025-02-16
Zmieniono
- Pokrycie funkcji liczy się teraz nawet, gdy narzędzie nie mówi, gdzie są funkcje. Eksport
func z TRACE32, samozamykające się elementy <method> z VectorCAST oraz zbiorcze method, % z EMMA — wszystkie trzy podają liczbę funkcji, nie mając gdzie umieścić CodeLens — wszystkie trzy były odrzucane przy wczytywaniu. Deklaracje pozostają preferowanym źródłem tam, gdzie istnieją; liczba jest teraz używana jako rozwiązanie zapasowe tam, gdzie ich nie ma.
0.2025.36 · build 4 — UCIS i Aldec UCDB, a nowe parsery przetestowane co do wiersza
2025-02-03
Dodano
- UCIS i UCDB XML — VHDL i Verilog, prosto z symulatora. Dwa dokumenty odpowiadają tej nazwie, a projekt ma ten, który napisał jego symulator, więc oba są czytane: standardowa forma wymiany Accellery
<UCIS> oraz własny ux:ucdb Aldeca, czyli to, co faktycznie produkuje acdb2xml z Active-HDL i Riviera-PRO. Pokrycie instrukcji i gałęzi jest przenoszone; pokrycie toggle, FSM, asercji i funkcjonalne nie jest czytane, a dokument zawierający tylko to informuje o tym, zamiast wczytać się pusty. - Otwarty VHDL już wcześniej niczego tu nie potrzebował: backend GCC w GHDL instrumentuje przez
-Wc,-ftest-coverage -Wc,-fprofile-arcs, a wynik przechodzi przez gcov, gcovr lub lcov. To wydanie jest dla komercyjnych symulatorów.
0.2025.35 · build 3 — EMMA XML, a Delphi w końcu ma tu wejście
2025-01-22
Dodano
- EMMA XML. Delphi w ogóle nie miał tu wejścia — ani lcov, ani Cobertura — a DelphiCodeCoverage zapisuje dokładnie ten schemat z
-xml. To także to, co wciąż emituje spora część starszych narzędzi Java, więc jeden parser otwiera język i jednocześnie porządkuje spuściznę. - Dodaj
-xmllines, a raport zyskuje prawdziwe liczniki trafień w wierszach, więc znaczniki działają; bez tego jest tylko procent zbiorczy, który dostaje podsumowanie pliku i brak znaczników zamiast zgadywania. Kropkowana nazwa pakietu staje się katalogiem tylko wtedy, gdy plik jest źródłem z rodziny Java; w raporcie Delphi to samo pole jest nazwą jednostki, a dodanie prefiksu wymyśliłoby folder, którego nikt nie ma na dysku.
0.2025.34 · build 3 — Lauterbach TRACE32, jedna miara na eksport
2025-01-01
Dodano
- Eksporty pokrycia TRACE32.
COVerage.EXPORT.ListModule zapisuje to, co debugger zmierzył na podstawie śladu na urządzeniu docelowym — nie instrumentowane źródło, lecz strumień instrukcji, który procesor faktycznie wykonał, na prawdziwym celu, bez żadnego wpływu sondy na czasy. Jeden eksport niesie jedną miarę naraz: stmt staje się pokryciem wierszy; dec/cond stają się pokryciem gałęzi; mcdc staje się MC/DC. Wczytaj dwa eksporty tego samego przebiegu, a połączą się według nazwy modułu. - Eksporty z pokryciem
func, call lub object były odrzucane po nazwie zamiast wczytywane puste, ze wskazaniem, jaką miarę zawiera plik — wszystkie trzy mają teraz swoje miejsce, odpowiednio w 0.2025.37, 0.2025.38 i 0.2025.39.
0.2025.33 · build 4 — Testwell CTC++, czytany według kolumny, bo tekst nie jest rozdzielany białymi znakami
2024-12-19
Dodano
- Listingi profilu wykonania Testwell CTC++.
ctcpost zamienia MON.sym i MON.dat w tekstowy listing o stałej szerokości — narzędzie stojące naprzeciw Bullseye w europejskich ocenach wbudowanych i bezpieczeństwa, mierzące pokrycie wielowarunkowe. Czytany według pozycji kolumny, a nie przez rozdzielanie białymi znakami, bo opis sam może zaczynać się cyfrą. - Wielowarunkowość to nie MC/DC i nie jest raportowana jako MC/DC. CTC++ liczy kombinacje warunków; MC/DC pyta, czy wykazano, że każdy warunek niezależnie wpływa na wynik. Umieszczenie tych liczb za bramą MC/DC dałoby audytorowi liczbę pod nazwą, której nie oznacza, więc tutaj są pokryciem gałęzi, czym w istocie są.
0.2025.32 · build 4 — VectorCAST XML, a MC/DC było po cichu odrzucane
2024-12-08
Dodano
- VectorCAST XML. VectorCAST zapisuje raport Cobertura aż do doctype, a potem dodaje atrybuty na to, czego zwykła Cobertura nie potrafi wyrazić. To oznaczało, że te pliki już się tu wczytywały i wyglądały na kompletne — a
mcdcpair-coverage było po cichu odrzucane przy wczytywaniu, właśnie tej publiczności, która kupiła narzędzie specjalnie po to, by je uzyskać. Te liczby par teraz przetrwają. Zasilają bramę MC/DC, procent i wynik złożony. - Pokrycie wywołań funkcji celowo nie jest przybliżane. Zwinięcie go w pokrycie gałęzi zawyżyłoby liczbę, która trafia do audytu; czeka, aż model będzie miał dla niego nazwę, co następuje w 0.2025.38.
Zmieniono
- Czytnik Cobertury niesie teraz dialekt:
<coverage line-rate=…> to rodzina, nie jeden format, a to, który dialekt jest czytany, podróżuje razem z parsowaniem zamiast być zgadywane element po elemencie.
0.2025.31 — Ada, Swift i pokrycie, które odświeża się samo
2024-11-07
Dodano
- GNATcoverage XML — nareszcie Ada. Zespoły awioniki DO-178C i kolejowe EN 50128 to dokładnie ten odbiorca, dla którego powstały ważony bezpieczeństwem wynik i obsługa MC/DC w tym produkcie, a do tej pory nie mogły tu wczytać niczego, chyba że ich
gnatcov był na tyle nowy, by emitować także Coberturę — która odrzuca wszystko poniżej wiersza. gnatcov coverage --annotate=xml zapisuje katalog, a nie plik: wczytaj pliki *.xml dla poszczególnych źródeł — otwarcie index.xml powie ci, gdzie naprawdę jest pokrycie, zamiast zawieść niejasno. Wiersz pokryty częściowo pozostaje wierszem pokrytym z niepokrytą decyzją: brak widać w pokryciu gałęzi i MC/DC, czyli tam, gdzie faktycznie jest. Obszary wyłączeń stają się wierszami wykluczonymi, zobowiązanie o nieustalonym stanie liczy się jako niepokryte, a nie pokryte, a przy --level=stmt+mcdc MC/DC liczone jest na warunek i zasila próg oraz wynik złożony.
- BullseyeCoverage i Visual Studio
.coveragexml. Bullseye to komercyjne narzędzie C/C++, które zespoły embedded i krytyczne dla bezpieczeństwa faktycznie posiadają; uruchom jego własne covxml i wczytaj wynik. Jego główną miarą jest pokrycie warunków/decyzji, a nie wierszy, i obie pozostają tu rozdzielone — dodatkowo sonda o jednym wyniku punktowana jest z jednego, a nie z dwóch, więc w pełni przetestowany switch nie jest raportowany jako pokryty w połowie. .coveragexml z Visual Studio domyka .NET dla zespołów na MSTest i vstest zamiast Coverleta: najpierw przekonwertuj binarny .coverage poleceniem dotnet-coverage convert. Wiersze pokryte częściowo przetrwają tę drogę w obu przypadkach.
- Ogólne pokrycie SonarQube — i jasna odpowiedź w sprawie Xcode. Cztery atrybuty na dwóch elementach, a liczy się dlatego, że niemal każde narzędzie, które nie potrafi wygenerować żadnego z pozostałych formatów, potrafi wygenerować ten: projekt, którego narzędzia pokrycia to rozszerzenie nigdy nie widziało, ma wreszcie drogę do środka. To także to, co zapisuje
xcresultparser, i tak trafiają tu projekty w Swift i Objective-C: samo .xcresult nie ma parsera, a dokumentacja mówi teraz dlaczego, zamiast zostawiać cię z domysłami — xccov podaje procenty, a nie dane na wiersz, a archiwum z danymi na wiersz czyta się tylko plik po pliku, w dokumencie, który nigdy nie nazywa opisywanego pliku.
- Pliki śladu spakowane gzipem wczytują się wprost.
gcov --json-format domyślnie zapisuje .gcov.json.gz, więc format ogłaszany w dokumentacji był tym, którego większość osób nie mogła wczytać. Rozpoznanie odbywa się po magicznych bajtach samego pliku, a nie po nazwie, więc skompresowany raport, który stracił swoje .gz, nadal działa — a każdy obsługiwany format może teraz przyjść spakowany, nie tylko ten z gcov.
- Swift i Objective-C, z własnego raportu Xcode.
xcrun xccov view --report --json to jedyny dokument pokrycia, jaki kompilacja iOS lub macOS tworzy bez dodatkowych narzędzi. Otrzymujesz procenty na plik, liczniki wykonań na funkcję i CodeLens. Nie zawiera danych na poziomie wiersza, a Studio ich nie zmyśla, więc marginesy pozostają puste dla tego formatu — zmyślonego oznaczenia nie da się odróżnić od zmierzonego. Aby uzyskać pokrycie Swift wiersz po wierszu, użyj llvm-cov export -format=lcov lub slather; oba już działały.
- Coveralls JSON — zapisywany przez reportery dla Elixira, Ruby, Pythona, Rusta, Go i JavaScriptu. Na poziomie wiersza, więc marginesy działają.
- Aktywne dni, zablokowane bramki i licencja, do której należy zestawienie — trzy dodatki do miesięcznego podsumowania użycia, dla instalacji, które włączyły telemetrię.
Usunięto
- Nazwa komputera nie jest już wysyłana.
hostname był w bazowej telemetrii od początku — poza wszelkimi bramkami, wysyłany przez każdego z włączoną telemetrią. Nazwa komputera to bardzo często czyjeś imię, numer biurka albo projekt klienta, a nie odpowiadała na żadne pytanie o użycie lepiej niż sam system operacyjny. Instalacja jest teraz identyfikowana wyłącznie przez losowy identyfikator instalacji. Dzięki temu nic, co nazywa Ciebie lub Twoją maszynę, jej nie opuszcza: ani nazwa komputera, ani nazwa użytkownika systemu, ani katalog domowy, ani interfejsy sieciowe, ani ścieżki plików, ani nazwa folderu projektu, ani etykieta zalogowanego konta. Zostaje system operacyjny, jego wydanie i architektura — jaki to rodzaj maszyny, a nie która.
- Telemetria jest teraz usuwana najpóźniej w ciągu 90 dni, podczas gdy polityka mówiła wcześniej tylko, że dane są “przechowywane, dopóki są przydatne”, co nie jest żadnym terminem.
Zmieniono
- Licencja płatna sama odświeża teraz pokrycie. Obserwowanie pliku pokrycia zawsze oznaczało pytanie „wykryto nowe pokrycie, wczytać?” po każdej kompilacji, na każdej warstwie — pytanie z jedną sensowną odpowiedzią, zadawane kilka razy na godzinę. To pytanie jest teraz zachowaniem bezpłatnej warstwy Community; licencja płatna po prostu wczytuje. Community zachowuje obserwatora, wykrywanie i pytanie, które zawsze miało.
- Niepasujący plik zostaje wskazany, wraz z kontrolą, która to udowodniła, przy licencji płatnej. Wykrywanie nie jest ograniczone i nie będzie: powiedzenie komuś, że jego pokrycie już nie opisuje jego pliku, nie jest czymś, co się sprzedaje. Community nadal otrzymuje ustalenie, a wiersz nadal jest przygaszony. Licencja płatna dodaje wskazanie — oznaczenie, plakietkę w Eksploratorze oraz wiersz, funkcję lub sumę kontrolną, która za tym stoi.
- Telemetria wysyła mniej i mówi, do kogo należy. Miesięczne podsumowanie nie zawiera już ścieżek plików, nazwy folderu Twojego projektu ani etykiety konta. Wymiana funkcji za telemetrię prosi teraz o adres e-mail, aby ten, kto się na nią zgodził, mógł dowiedzieć się, co wysyła jego instalacja, i zażądać usunięcia tych danych.
- Poprawiono trzy opisy ustawień.
watch.enabled, staleWarning.enabled i telemetry.enabled rozminęły się z tym, co robi kod — telemetry.enabled najbardziej: opisywał wysyłanie znacznie większej ilości danych, niż jest wysyłana.
Naprawiono
- Okno wyboru pliku nie ukrywa już formatów, które czyta. Pick Coverage File filtrowało do
info, json i xml, więc coverage.out z Go i .gcov.json.gz z gcov — oba formaty, które to rozszerzenie czyta — były wyszarzone w tym samym oknie, które prosi o wybór jednego z nich.
- Zwykła instalacja Community nie wysyła już strony swojego kodu źródłowego. Kontrola chroniąca próbkę kodu traktowała każdą instalację Community tak, jakby przyjęła wymianę telemetryczną, a nie tylko te, które faktycznie ją przyjęły.
- Jedno ostrzeżenie na wczytanie zamiast dwóch — plik, który już nie pasuje do swojego pokrycia, prawie zawsze był też edytowany po przebiegu, a każda rzecz była zgłaszana osobno.
- Odinstalowanie nie zgłasza już nazwy użytkownika systemu ani katalogu domowego osoby, której licencja tego zabrania.
0.2025.30 · build 3 — To, co twoja kompilacja i tak już zapisuje
2024-10-18
Dodano
- Profile pokrycia Go.
go test -coverprofile to jedyne wyjście pokrycia, jakie tworzy standardowy zestaw narzędzi Go — nie ma lcov, na którym można się oprzeć, jak w Rust, Dart czy Elixirze — więc projekt w Go nie miał niczego, co to rozszerzenie mogłoby odczytać. Profil zapisuje bloki, a nie wiersze, i każdy wiersz objęty blokiem przejmuje jego licznik, wraz z klamrą zamykającą, dokładnie tak, jak podświetla je go tool cover -html. coverage.out dołącza do domyślnie wyszukiwanych nazw, więc projekt w Go bez żadnej konfiguracji znajduje swój profil tak, jak projekt w C znajduje lcov.info.
- Clover XML i OpenCover XML. Clover to jest to, co projekty PHP mają naprawdę:
php-code-coverage potrafi wypisać Coberturę, ale Clover jest jego domyślnym formatem i tym, który konfiguruje niemal każdy phpunit.xml — pokrycie PHP było więc tu nieczytelne, podczas gdy parser Cobertury czekał na wyjście, którego prawie nikt nie generuje. Reporter clover w Istanbulu zapisuje ten sam dokument, więc tak skonfigurowany projekt Jest również jest objęty. OpenCover to odpowiednik dla .NET: C# i VB.NET docierały już jako Cobertura, która spłaszcza decyzję do łańcucha condition-coverage="50% (1/2)", przez co informacja o tym, która gałąź się wykonała, znikała, zanim parser ją zobaczył. OpenCover zachowuje licznik odwiedzin dla każdej gałęzi — różnica między wiedzą, że połowa rozgałęzienia jest pokryta, a wiedzą która połowa.
- JSON z coverage.py oraz z gcov/gcovr. Eksporty coverage.py do Cobertury i lcov muszą nazwać wiersz z
# pragma: no cover albo pokrytym, albo brakującym, bo nie mają słowa na „celowo wykluczony” — a to rozszerzenie je ma: tę samą flagę, którą stawiają jego znaczniki LCOV_EXCL. Pragmy projektu w Pythonie znaczą więc tutaj to, co znaczą w samym raporcie coverage.py. Pokrycie GCC z kolei docierało dopiero po przejściu przez lcov lub gcovr -x: drugie narzędzie, by przekonwertować dane, które GCC już wytworzył. gcov --json-format --stdout i gcovr --json dają niemal identyczne dokumenty, a jeden parser czyta teraz oba.
Naprawiono
- Komentarze są czytane w języku, w którym napisano plik. Skaner wierszy niebędących kodem napisano dla C i stosowano do każdego pliku, co było poprawne, dopóki każdy format czytany przez to rozszerzenie opisywał język z rodziny C. Już nie jest: skaner C napotykający
# don't widzi, że apostrof otwiera łańcuch, nigdy nie widzi jego zamknięcia i liczy wiersz komentarza jako kod — liczba po cichu nieco błędna, a nic tego nie sygnalizuje. Teraz jest to # dla Pythona, Ruby, powłoki, Perla, R, Elixira i Julii; wszystkie trzy formy dla PHP, który przyjmuje wszystkie trzy; oraz // z /* */ dla reszty, co pozostaje domyślne dla nieznanego rozszerzenia — #define jest kodem, a wykluczenie go byłoby błędem w drugą stronę.
0.2025.29 · build 4 — Każde ustawienie, objaśnione
2024-10-15
Dodano
- Każde ustawienie
fuciniCoverage.* ma teraz swoje miejsce w tym panelu, a nie tylko trzynaście ustawień zgodności. Wszystkie pięćdziesiąt pięć pogrupowano w te same sekcje i w tej samej kolejności co w opublikowanym przewodniku po ustawieniach, więc strona, z której konfigurujesz, i strona, którą czytasz, zgadzają się co do tego, gdzie mieszka ustawienie. Pole wyszukiwania filtruje po nazwie, kluczu lub opisie; lista skrótów przenosi między sekcjami. Formularz jest w czasie działania wyprowadzany z własnego dołączonego manifestu rozszerzenia — typy, wartości domyślne, zakresy, wyliczenia i każde słowo tekstu — więc nic o ustawieniu nie jest zapisane dwa razy, a panel nie może rozejść się z rozszerzeniem, które edytuje.
- Opisy podążają za językiem, który przypiąłeś. VS Code ustala lokalizację manifestu na podstawie języka interfejsu edytora przy ładowaniu rozszerzenia i nie daje sposobu, by nadpisać to dla pojedynczego rozszerzenia — ustawienie
fuciniCoverage.language na niemiecki w angielskim edytorze tłumaczyło więc wszystko poza ustawieniami. Ponieważ panel sam czyta i rozwiązuje te pliki, jest jedynym miejscem, które może uszanować ten wybór.
- Kontrolki, o które schemat JSON nie potrafi poprosić. Nic w schemacie ustawień nie oznacza ciągu jako ścieżki, więc natywny interfejs nie może zaproponować selektora; trzy ustawienia zawierające katalog mają teraz przycisk Przeglądaj….
coverageFile.paths i pathRemap otrzymują prawdziwe edytory list zamiast surowego pola JSON, a każdy kolor colorScale — próbkę obok wartości szesnastkowej.
Zmieniono
- Zapis zapisuje to, co zmieniłeś, i nic poza tym. Przy trzynastu ustawieniach niewiele znaczyło, że Zapisz zapisywało wszystkie trzynaście; przy pięćdziesięciu pięciu oznaczałoby to, że jedna zmiana wtłacza całą przestrzeń nazw do
settings.json, w którym były dwie linie. Zapisywane są tylko ustawienia, których wartość faktycznie się zmieniła, a wartość równa domyślnej usuwa nadpisanie, zamiast powtarzać to, co rozszerzenie i tak dostarcza.
- Klucz licencji zawsze trafia do ustawień użytkownika, a wiersz o tym mówi.
license.key zadeklarowano w zakresie aplikacji, co oznacza, że VS Code czyta go wyłącznie stamtąd — zapisanie go w obszarze roboczym to zapis, który wygląda na udany i niczego nie zmienia. Przywróć czyści teraz wszystkie pięćdziesiąt pięć kluczy w wybranym zakresie zamiast trzynastu, więc najpierw pyta. A zmiana dokonana poza panelem nie kosztuje już utraty miejsca: strona porównuje przed przerysowaniem, więc Zapisz nie przewija już pięćdziesięciu pięciu wierszy na początek.
0.2025.28 · build 3 — Trzynaście wierszy, jedna decyzja
2024-10-12
Dodano
- Tryb zgodności, siedem bramek progowych i sześć wag wyniku złożonego mają teraz jeden edytor. W interfejsie ustawień to trzynaście niepowiązanych wierszy, a w praktyce jedna decyzja: próg nie robi nic, dopóki obowiązujący tryb go nie uwzględni, a waga nie robi nic, dopóki nie decyduje bramka ważona. Fucini Coverage: Configure Coverage Compliance & Thresholds..., pod przyciskiem koła zębatego na pasku tytułu widoku Coverage, łączy te trzy rzeczy, wyjaśnia każdy tryb tam, gdzie tryb się wybiera, i nazywa sposoby skonfigurowania bramki tak, by niczego nie sprawdzała — tryb ścisły bez ustawionego progu dla żadnej metryki, tryb ważony z progiem
0, wagi równe 0 — jako ostrzeżenia, kiedy właśnie na nie patrzysz.
- Pokazuje werdykt z wyprzedzeniem i zapisuje przez VS Code. ZGODNY / NIEZGODNY, który niezapisany formularz dałby dla wczytanego przebiegu, oblicza własny silnik zgodności rozszerzenia, a nie druga kopia reguł: podgląd, który może być sprzeczny z bramką, jest gorszy niż brak podglądu. Zmiany idą przez zwykłe API konfiguracji do
settings.json — użytkownika albo obszaru roboczego, wedle wyboru — więc VS Code formatuje plik i zachowuje jego komentarze; zmiana wprowadzona ręcznie lub w innym oknie wraca do otwartego formularza, niezależnie od tego, czy przebieg jest wczytany. Licencja nie jest potrzebna: Community dostaje ten sam edytor co Pro.
Naprawiono
- Przycisk powiadomienia o aktualizacji pokazywał
Download && Install. Podwojony ampersand to znak ucieczki dla mnemoników, właściwy w tytułach w package.json i w oknach modalnych — ale przyciski akcji w powiadomieniu biorą swoją etykietę jako zwykły tekst, więc oba znaki były wypisywane dokładnie tak, jak je zapisano, we wszystkich 17 językach, każdemu, komu zaproponowano aktualizację.
0.2025.27 · build 7 — Wymiana, na którą sam się decydujesz
2024-09-30
Zmieniono
- Telemetria jest domyślnie wyłączona. Dostarczano ją włączoną, z uzasadnieniem, że okres oceny potrzebuje tych danych. To uzasadnienie przestało obowiązywać, gdy poziom Community uczynił włączenie telemetrii tym, co bezpłatnie odblokowuje wszystkie funkcje Pro: wymiana znaczy coś tylko wtedy, gdy dokonuje jej sama osoba, a wymiana, na którą nikt się nie zdecydował, nie jest wymianą. Nic nie jest wysyłane, dopóki jej nie włączysz, a Community i tak działa dalej ze swoim standardowym zestawem funkcji.
- Ustawienie telemetrii mówi, czemu służy, a po resztę odsyła. Jego opis wyliczał wcześniej każde pole niesione przez ping, co oznaczało dwie kopie tej listy — jedną w ustawieniu, drugą w polityce prywatności — które miały na zawsze pozostać identyczne, a nie były. Teraz mówi, co daje włączenie, i odsyła do polityki prywatności po listę pól, więc jest jedna lista do utrzymania w zgodzie z prawdą zamiast dwóch.
- Instalacja tego wydania jednorazowo ponownie otwiera Twój okres oceny. Każdy, komu okres próbny już upłynął, dostaje nowe 14 dni, ponieważ to wydanie zmienia warunki, w jakich oceniał: okres próbny spędzony z telemetrią domyślnie włączoną nie był okresem próbnym produktu oferowanego teraz. Jest to celowo powiązane z jednorazowym tokenem, a nie z wersją — resetowanie przy każdym wydaniu oznaczałoby, że okres próbny nigdy się nie kończy dla kogoś, kto się aktualizuje, a to nie okres próbny, lecz licencja bez ceny z dodatkowymi krokami. Token zostaje zużyty przy pierwszej aktywacji, po czym wracają zwykłe zasady. Licencja płatna pozostaje nietknięta, bo weryfikacja klucza kończy się, zanim okres próbny w ogóle zostanie sprawdzony, a Community nie jest objęte, bo ta edycja nie ma okresu próbnego do ponownego otwarcia.
- Klucz licencyjny nie kosztuje już ankiety. Komunikaty aktywacyjne, ustawienie klucza licencyjnego i okno po zakończeniu okresu próbnego przedstawiały klucz jako coś wydawanego w zamian za odpowiedzi na pytania. Tak nie jest: klucz jest wydawany automatycznie na żądanie, a ankieta zwrotna jest dobrowolna i całkowicie odrębna.
Naprawiono
- Trzy miejsca wciąż obiecywały okres próbny „do 2026-12-31”. Taka data nigdy nie istniała w produkcie — okres próbny trwa 14 dni, liczonych na instalację od pierwszego użycia. Dwa wcześniejsze wydania wychwyciły to twierdzenie w opisach ustawień i w pliku README; przetrwało w ramce ewaluacyjnej na tej stronie, w Podręczniku użytkownika i w pliku README narzędzi licencyjnych. Podręcznik użytkownika był najgorszy z trzech: twierdził, że okno obowiązuje „dla każdej instalacji, na całym świecie, naraz (a nie jako odliczanie per instalacja)”, czyli dokładnie odwrotnie, i że renderowanie pokrycia jest wstrzymywane po zakończeniu okresu próbnego, podczas gdy w rzeczywistości rozszerzenie przechodzi na bezpłatny poziom Community.
- Powiadomienia e-mail telemetrii wychodziły z niewłaściwej domeny. Nagłówek
From: wskazywał skrzynkę w fucini.consulting, podczas gdy serwer, który je wysyła, to fucini.software — dokładnie ta zgodność, przed której brakiem ostrzega własny komentarz przy tym ustawieniu, i pewny sposób na to, by poczta trafiła do spamu albo została wprost odrzucona.
0.2025.26 · build 2 — Wyszarzone, nie usunięte
2024-08-27
Zmieniono
- Plik, który raport wymienia, a którego nie ma na dysku, pokazuje się tam, gdzie należy — wyszarzony i z wyjaśnieniem. Wersja 0.2025.25 przestała wymyślać lokalizacje dla takich plików, i słusznie, ale zostawiała im ścieżkę względną, która wcale nie jest lokalizacją — drzewo nadal robiło więc projekt z jej pierwszego segmentu, a trzy usunięte źródła podmodułu siedziały w widmowym
app obok podmodułu, z którego naprawdę pochodziły. Niezgodność była widoczna, o to chodziło, ale w złym miejscu i nie mówiła nic o tym, co jest nie tak.
- Teraz pojawia się w projekcie, z którego został zmierzony, w folderze, w którym umieszcza go raport — narysowany w średniej szarości motywu i kursywą zamiast zwykłym kolorem tekstu. Po najechaniu pokazuje ścieżkę, którą by miał, i wyjaśnia, że nic tam nie ma — najprawdopodobniej zmieniono nazwę lub usunięto go po wygenerowaniu raportu — oraz że jego liczby nadal się liczą. Nic nie jest pomijane i żadna suma się nie zmienia: wiersz jest własnym świadectwem raportu, a wyszarzenie jest tym, co powstrzymuje go od wyglądania jak wiersz, który się otwiera.
- Domysł zostaje wewnątrz widoku. Zapisana ścieżka pliku to nadal dokładnie to, co powiedział raport, bo wszystko inne jest po niej kluczowane — wzbogacanie zewnętrznego raportu się z nią porównuje, telemetria ją urelatywnia, widok z adnotacjami ją otwiera — a danie im przypuszczalnej lokalizacji zamieniłoby znane na wymyślone. Tylko drzewo łączy jedno z drugim, i tylko dla ścieżki, która nie nazywa własnej lokalizacji: ścieżka bezwzględna, której po prostu nie ma, zachowuje to, co powiedział raport, i jest wyszarzana tam, gdzie stoi.
0.2025.25 · build 4 — Gdzie mierzono
2024-08-07
Naprawiono
- Pokrycie podmodułu ląduje tam, gdzie podmoduł naprawdę jest, a jego wiersze się otwierają. Podmoduł gita buduje własny raport obok własnego drzewa, a gcovr zapisuje w nim
<source>.</source> — „katalog, w którym leży ten plik” — z nazwami w rodzaju app/Application.cpp poniżej. Nic nie kotwiczyło tej . w niczym: ścieżki rozwiązywano raz, po scaleniu, gdy przebieg nie wiedział już, z którego wejścia pochodzi dany plik, więc jedyną pozostałą bazą był korzeń obszaru roboczego. Próba <workspace>/app/Application.cpp nie znajdowała nic, każda ścieżka pozostawała względna, a widok pokrycia rysował je jako projekt o nazwie app — od pierwszego segmentu ścieżki, która nigdy nie była lokalizacją — którego każdy wiersz kopiował i otwierał tam, gdzie żadnego pliku nie było.
- Ścieżki są teraz rozwiązywane per plik śledzenia, przed scaleniem. Względny
sourceRoot jest zakotwiczony w katalogu, w którym leży jego plik śledzenia, więc . obok coverage.xml podmodułu oznacza ten podmoduł. Gdy to nie znajdzie źródeł, wyszukiwanie idzie w górę od pliku śledzenia — typowy układ CMake zapisuje pokrycie kilka poziomów w głąb build/, a którego z dwóch kształtów używa projekt, nie jest zapisane nigdzie w raporcie, więc odpowiada system plików, a nie konfiguracja. Wędrówka zatrzymuje się na korzeniu obszaru roboczego: dalej samo src/main.c mogłoby się rozwiązać w sąsiednim checkoucie o tym samym układzie — zła odpowiedź, która wygląda na dobrą. Ścieżka już bezwzględna i istniejąca zostaje nietknięta, więc zwykłe przebiegi lcov się nie zmieniają.
- Podmoduł pozostaje własnym projektem w widoku pokrycia. Pliki rozwiązujące się teraz wewnątrz obszaru roboczego wpadłyby inaczej do jego drzewa — foldery podmodułu przeplecione z rodzicem, a jego liczby dodane do sumy rodzica, jakby jedną bazę kodu zmierzono dwa razy. Każdy plik zapamiętuje korzeń, z którego był mierzony, a widok grupuje po nim, więc podmoduł zachowuje własny nagłówek i własne sumy, choć leży w otwartym folderze. Przebieg o i tak bezwzględnych ścieżkach nie ma takiego korzenia i grupuje się dokładnie jak wcześniej.
- Plik, który raport wymienia, a którego już nie ma, nadal jest zgłaszany jako brakujący. Nie dostaje wiarygodnej ścieżki, pod którą go nie ma: raport wymieniający usunięte już pliki jest raportem nieaktualnym, a rysowanie ich w zmyślonych miejscach by to ukryło. Każdy jest wymieniony w kanale wyjściowym pod
FUCINI_REMAP_001, wraz ze ścieżką, którą by miał.
0.2025.24 · build 3 — Dlaczego zniknęło Twoje stanowisko
2024-07-27
Zmieniono
- Stanowisko, które znika, mówi teraz dlaczego. Każde cofnięcie pokazywało ten sam wiersz — Twoje stanowisko w tym planie nie jest już aktywne — co brzmi jak zarzut skierowany pod niewłaściwym adresem. Subskrypcja zespołowa zmniejszona poniżej liczby używanych stanowisk zwalnia teraz nadwyżkę po okresie karencji, a ten, kto traci stanowisko, nie zrobił nic poza tym, że najdłużej z niego nie korzystał. Tam, gdzie serwer licencji ma coś pożytecznego do powiedzenia, rozszerzenie to mówi: stanowisko zwolnione, by zmieścić się w zmniejszonej subskrypcji, wyjaśnia dokładnie to i wskazuje osobę, która nią zarządza, a przycisk Poproś o nowy klucz nadal jest dostępny — bo droga powrotna jest realna: w puli zrobi się miejsce, gdy tylko ta osoba je zwolni.
- Zakończona subskrypcja nie oferuje przycisku. Z wygasłej subskrypcji nie można wydać nowego klucza, więc jedyne działanie w tym powiadomieniu mogło się tylko nie powieść — co brzmi jak zepsute rozszerzenie, a nie jak zakończona subskrypcja. Teraz mówi, co się stało, i na tym poprzestaje. Każdy powód, którego ta kompilacja nie rozpoznaje, zachowuje ogólne brzmienie: serwer licencji jest wdrażany na bieżąco, a zainstalowane rozszerzenie nie, więc napotkanie nieznanego powodu jest przypadkiem zwykłym, a nie skrajnym — nigdy nie pokazuje surowego identyfikatora i nigdy nie milknie. Oba nowe komunikaty przetłumaczono na wszystkie siedemnaście języków.
0.2025.23 · build 5 — Poza rozszerzenie
2024-07-17
Dodano
- Przebieg może wreszcie wyjść na zewnątrz, w sześciu kolejnych formatach. Dotąd wyjścia były dwa: Fucini JSON, którego nie czyta nic poza rozszerzeniem, i raport HTML, którego maszynowo nie czyta nic. Export Coverage Report... otwiera wybór formatu i zapisuje aktywny przebieg jako CSV na plik (pokryte/łącznie/procent dla wierszy, gałęzi, funkcji, MC/DC, regionów i instancjacji, najgorsze na początku, z wierszem
TOTAL), jako CSV na funkcję (liczba wywołań, czy się wykonała, niepokryte gałęzie w środku, pary MC/DC), jako podsumowanie Markdown do wklejenia w pull requeście, jako plik śledzenia LCOV, XML Cobertura, SARIF, albo jako samodzielną odznakę SVG do pliku README. Znajdziesz go w palecie poleceń, na pasku tytułu widoku Covered Files obok Generate Full HTML Report oraz w szybkim menu paska stanu, gdy quickActions.exportReport jest włączone.
- To teraz konwerter, nie tylko przeglądarka. Rozszerzenie czyta już lcov, llvm-cov JSON, Coberturę, JaCoCo, Istanbul/nyc i SimpleCov; z zapisem LCOV i Cobertury potrafi też pójść w drugą stronę. Wczytaj raport JaCoCo albo kilka raportów scalonych w jeden przebieg i wypisz ten jeden plik śledzenia, który akceptują genhtml, Codecov, Coveralls i SonarQube — albo XML, który Jenkins, GitLab i Azure DevOps wczytują natywnie. Oba przechodzą z powrotem przez własne parsery rozszerzenia, a zakresy wierszy są rozwijane wiersz po wierszu, żeby zapisane
LF/LH zgadzały się z procentem na ekranie, zamiast go przybliżać.
- Każdy zapis mówi, co pomija. Wszystko poza CSV jest stratne, i to po cichu: MC/DC, regiony kodu i instancjacje C++ nie mają odpowiednika w LCOV, Coberturze ani SARIF, a Cobertura zapisuje, ile warunków wiersza pokryto, nie którą gałąź. Fucini JSON i dwa CSV pozostają formatami niosącymi wszystko, co zmierzono. W CSV metryka, której przebieg nie ma, zostawia komórki puste, a nie zerowe — pusta komórka mówi „to narzędzie nie zgłosiło danych o gałęziach”,
0 powiedziałoby „nie trafiono w żadną gałąź”, a arkusz kalkulacyjny nie odróżni ich później. Wszystko, co arkusz wykonałby jako formułę — pole zaczynające się od =, +, - lub @, czyli każda ścieżka npm z zakresem — jest cytowane i rozbrajane przed zapisem.
- SARIF opisuje różnicę; odznaka nie potrzebuje sieci. Niepokryte zakresy zgłaszane są na poziomie
note, nie warning: niepokryty kod mówi coś o zestawie testów, a skanowanie kodu traktuje ostrzeżenie jak coś, co powinno blokować — bramką, która blokuje, pozostaje Check Coverage Thresholds. Odznaka jest rysowana tutaj, a nie pobierana z shields.io, więc działa w odciętym lub lokalnym repozytorium i bierze kolor z tej samej colorScale co marginesy i pasek stanu. W darmowej edycji Community wybór się otwiera i oba CSV działają, z limitem 20 eksportów dziennie jak Export Fucini JSON; formaty wymiany są płatne, wzdłuż tej samej linii, którą ta edycja zawsze rysowała: czytanie własnych liczb jest darmowe, karmienie potoku CI nie.
0.2025.22 · build 3 — Nie ma czego mierzyć
2024-06-24
Naprawiono
- Plik, w którym nie ma czego instrumentować, nie jest już raportowany jako pokryty w 100%. Nagłówek zawierający same deklaracje — prototypy, makro, strażniki include — nie ma ciał funkcji, więc kompilator nie emituje dla niego żadnego mapowania pokrycia, a wszystko, co dzieli zero przez zero, odpowiada 100%. Stał w drzewie na zielono, obok kodu naprawdę przetestowanego. Oba czytniki biorą teraz sumy samego narzędzia jako relację pliku o sobie —
LF/FNF/BRF w lcov, blok summary w JSON-ie llvm-cov — a plik, którego wszystkie sumy wynoszą zero, zostaje poza przebiegiem, zamiast być oceniany. Zapisy wierszowe pod tymi sumami są celowo pomijane: rozwinięcie makra przypisuje się wierszowi, który je definiuje, podczas gdy licznik należy do wiersza, który go używa, w innym pliku, i to właśnie ten pożyczony wiersz był jedynym powodem, dla którego taki nagłówek wyglądał na zmierzony. Sumy przebiegu również go tracą, więc główna liczba jest nieco niższa i znacznie prawdziwsza. Każda pominięta ścieżka jest wymieniona w kanale wyjściowym, a raport, w którym wszystkie pliki są samymi deklaracjami, zachowuje je wszystkie.
Zmieniono
- Wybranie pliku pokrycia dokłada się do już wczytanych, zamiast je zastępować. Kompilacja zapisująca jeden raport na moduł nie ma pojedynczego pliku do przypięcia, a wybranie raportu drugiego modułu po cichu usuwało pierwszy. Okno dialogowe przyjmuje teraz kilka plików naraz, każdy wybór dokłada się do zestawu, a wszystko wybrane jest scalane w jeden przebieg — rysowany w panelu pod własną nazwą każdego projektu. Obserwacja obejmuje je wszystkie, a przebudowany raport nie usuwa już pozostałych z ekranu. Show Loaded Coverage Files kończy się pozycją Usuń wybrane pliki, która wraca do zwykłego wyszukiwania.
- Wsparcie ma adres we własnej domenie produktu:
support@fucini.software. Gdy aktywacja nie może dokończyć się sama, panel licencji i komunikat z kodem żądania podawały adres fucini.consulting — inną domenę niż wszystkie pozostałe odnośniki rozszerzenia, czytaną jak inna firma. license@fucini.software pozostaje bez zmian: stamtąd przychodzą klucze, to nie skrzynka do pisania.
0.2025.21 — Czyj to src
2024-06-21
Dodano
- Każde drzewo w widoku Coverage mówi teraz, do którego projektu należy. Wersja 0.2025.19 dawała scalonemu uruchomieniu po jednym nazwanym bloku na projekt, ale zwykłe uruchomienie wciąż rysowało gołe drzewo — obszar roboczy przycięty do własnego folderu otwierał się więc na
src, a nic powyżej nie mówiło, który to src. Każde drzewo niesie teraz swój korzeń: foldery prowadzące do projektu w wyciszonym kolorze, a własny folder projektu za nimi w pełnym. Drzewo przycięte do folderu obszaru roboczego nadal mówi, do czego zostało przycięte, a dwie bazy kodu scalone w jedno uruchomienie nigdy nie są czytane jako jedno drzewo. To nagłówek, a nie wiersz — nie ma tam czego rozwijać, a foldery poniżej zwijają się dokładnie tak jak wcześniej. W wąskim panelu najpierw skracają się katalogi wiodące, więc folder, który faktycznie nazywa projekt, znika jako ostatni, a najechanie kursorem pokazuje całą ścieżkę.
0.2025.20 · build 7 — Menu, którego się spodziewałeś
2024-06-08
Dodano
- Wiersze widoku Coverage mają menu kontekstowe samego Eksploratora. Kliknięcie prawym przyciskiem pliku lub folderu otwierało dotąd Wytnij/Kopiuj/Wklej z widoku sieciowego — trzy pozycje, którym nic nie podlegało. Teraz otwiera się prawdziwe menu VS Code: Otwórz, Open to the Side, Otwórz za pomocą…, Reveal in Explorer View, Reveal in File Explorer, Open in Integrated Terminal, Znajdź w folderze… dla folderu oraz Copy Path / Copy Relative Path — obok nich w systemie Windows warianty z ukośnikami, tam gdzie obie formy się różnią. Przycisk
⋯ i jego menu pozostają bez zmian i są ostatnią pozycją nowego menu.
Zmieniono
- Metryka, dla której plik pokrycia nie zawiera danych, nie jest już oceniana. Próg dla MC/DC przy braku MC/DC w kompilacji liczył się jako niepowodzenie — plik ze 100% w każdej faktycznie zmierzonej metryce trafiał pod kartę „spełniono 3 z 5”, wobec poprzeczki, której nic w tym pliku nigdy nie mogło pokonać. Metryki bez danych są teraz pomijane wszędzie tam, gdzie powstaje werdykt: na pasku stanu dla pliku, na karcie całego przebiegu, w banerze nad kodem z adnotacjami i w raporcie HTML. Check Coverage Thresholds wciąż wprost nazywa brakującą metrykę — i tam jest na to miejsce.
- Pliki, w których nie ma nic mierzalnego, nie trafiają już do widoku Coverage. Nagłówek z deklaracjami, plik z samymi reeksportami, moduł wyłącznie z typami: żaden napisany przez ciebie test nie zmieni ich liczby, a po otwarciu nie widać żadnych metryk. W 0.2025.19 miały myślnik; teraz po prostu ich nie ma, a wraz z nimi znikają foldery, które przez to zostały puste. Przebieg, w którym nic nie jest mierzalne, nadal pokazuje wszystko.
Naprawiono
- Litera dysku wciąż mogła stać na szczycie drzewa. Przy pokryciu, którego ścieżki nie leżą pod otwartym folderem roboczym — scalony plik z innego projektu albo okno bez otwartego folderu — drzewo zaczynało się od
W:, a w systemach Linux i macOS od wiersza zupełnie bez nazwy: jeden wiersz z dokładnie jednym dzieckiem, który nie ma po co rozwijać. Korzeń systemu plików nigdy już nie jest rysowany, niezależnie od ścieżek, a każdy wiersz nadal niesie swoją prawdziwą ścieżkę bezwzględną dla menu i edytora.
0.2025.19 · build 6 — Ścieżki, nie wstęp
2024-05-16
Dodano
- Menu wiersza przy każdym pliku i folderze w widoku Coverage. Przycisk na końcu wiersza kopiuje tę ścieżkę w każdej z czterech postaci, jakich może oczekiwać edytor, powłoka lub prompt — bezwzględnej albo względnej wobec obszaru roboczego, z separatorami systemu albo z ukośnikami — i oferuje Reveal in File Explorer oraz Open in Integrated Terminal, przy czym dla pliku terminal otwiera się w jego własnym katalogu. Pozycje z ukośnikami pojawiają się tylko tam, gdzie różnią się od postaci natywnej, więc w systemach Linux i macOS menu jest krótsze o dwie pozycje. Skopiowanie ścieżki oznaczało dotąd odnalezienie tego samego pliku po raz drugi w Eksploratorze.
- Przyciski zwijania i rozwijania wszystkiego nad drzewem. Zwinięcie wszystkiego i otwarcie jednego interesującego folderu to najszybsza droga przez duże drzewo, a dotąd kosztowała jedno kliknięcie na folder. To, co zwiniesz w ten sposób, jest zapamiętywane tak samo jak folder zamknięty ręcznie, więc przeładowanie tego nie cofnie.
- Scalony przebieg obejmujący więcej niż jeden projekt rysuje teraz każdy projekt osobno, pod jego własną nazwą. Scalenie pliku śledzenia z drugiej bazy kodu wieszało dotąd jego foldery na tym samym drzewie co foldery obszaru roboczego, więc
src pojawiał się dwa razy bez wyjaśnienia, a katalogi obu projektów przeplatały się alfabetycznie. Każdy projekt dostaje teraz własny nazwany blok, oddzielony linią, a pierwszy jest ten z obszaru roboczego. Przebieg obejmujący jeden projekt pozostaje bez zmian i nie ma nagłówka — nie byłoby od czego go odróżniać.
Naprawiono
- Plik bez niczego wykonywalnego był raportowany jako pokryty w 0%. Moduł zawierający wyłącznie reeksporty
export * albo same deklaracje typów kompiluje się do czegoś, czego narzędzie pokrycia nie potrafi zmierzyć — plik śledzenia nie zapisuje więc dla niego żadnej instrukcji. Widok Coverage oceniał to na 0% i stawiał plik na czerwono obok kodu, który naprawdę jest nieprzetestowany, choć nie ma tam czego testować; Eksplorator tymczasem oznaczał ten sam plik zielonym 100%, ponieważ pusta suma czyta się jako „pokryto wszystko z niczego”. Żadna z tych liczb nie była prawdziwa i żadna nie jest już pokazywana: wiersz w panelu dostaje myślnik i przerywaną obwódkę z podpowiedzią wyjaśniającą dlaczego, a plakietka w Eksploratorze zostaje pominięta. Folder zawierający wyłącznie takie pliki także pozostaje bez oceny. Plik mający 0% czegoś, co faktycznie zmierzono, nadal pokazuje 0% — myślnik znaczy „nie ma czego mierzyć”, a nie „zmierzone i chybione”. - Wiersze ze scalonego projektu wskazywały niewłaściwe miejsce. Ich ścieżki były budowane od katalogu głównego obszaru roboczego, a nie własnego, więc dla pliku spoza obszaru roboczego menu wiersza kopiowało — a „Reveal in File Explorer” otwierało — ścieżkę, pod którą pliku nigdy nie było. Teraz niosą katalog główny, z którego faktycznie pochodzą.
Zmieniono
- Widok Coverage nie rysuje już katalogu głównego obszaru roboczego. Drzewo zaczynało się od korzenia systemu plików i schodziło przez każdy folder powyżej projektu — dysk, potem katalog z Twoimi projektami, potem sam projekt — zanim dotarło do pierwszego folderu, który naprawdę należał do Ciebie. To było kilka poziomów wcięcia, w każdym wierszu, powtarzających to, co mówił już tytuł okna. Ścieżki zaczynają się teraz od folderu obszaru roboczego. Pełna ścieżka bezwzględna to wciąż to, co kopiuje menu wiersza i co otwiera edytor.
0.2025.18 · build 4 — Zostaje tam, gdzie je zostawisz
2024-04-30
Naprawiono
- Foldery zwinięte w widoku Coverage rozwijały się ponownie przy każdym przeładowaniu. Obserwowanie jest domyślnie włączone, więc build, który na nowo generuje pokrycie, przerysowuje panel — a ponieważ każdy folder był rysowany jako rozwinięty, zwinięcie wytrzymywało tylko do następnego builda. Przy dużym drzewie oznaczało to wykonywanie tej samej pracy kilka razy na godzinę. Panel pamięta teraz, które foldery zamknąłeś, i zostawia je zamknięte. Katalog, który pojawia się po raz pierwszy w późniejszym przebiegu, nadal jest pokazywany jako rozwinięty, jak każdy inny: zapamiętywany jest świadomy akt zamknięcia, a nie stan domyślny.
- Wyłączenie telemetrii nie zatrzymywało sygnału o odinstalowaniu. Ten sygnał wysyła mały samodzielny skrypt, który VS Code uruchamia podczas odinstalowywania. Nie ma on dostępu do API VS Code i nie może odczytać Twoich ustawień, więc jedynym, co każe mu niczego nie wysyłać, jest brak pliku, który rozszerzenie zapisuje, gdy telemetria jest włączona — a ten plik nigdy nie był usuwany po wyłączeniu telemetrii. Każdy, kto miał ją włączoną, a później ją wyłączył, i tak wysłałby przy odinstalowaniu swoją nazwę użytkownika systemu, nazwę hosta i katalog domowy. Plik jest teraz usuwany w chwili wyłączenia telemetrii.
- Odnowienie Pro mogło zgłosić sukces dla klucza, który właśnie zastąpiłeś. Ciche odnowienie odczytywało skonfigurowany klucz dwukrotnie: raz, by zdecydować, czy odnawiać, i ponownie potem, by zdecydować, czy cokolwiek komunikować. Wklejenie nowego klucza w trakcie odnawiania sprawiało, że drugi odczyt widział inny klucz, a komunikat „Twoja subskrypcja Pro została odnowiona” opisywał ten, który został zastąpiony. Teraz klucz jest odczytywany raz.
Zmieniono
- Każdy moduł rozszerzenia jest teraz pokryty własnymi testami. W przypadku narzędzia, którego całym zadaniem jest mówienie Ci, do czego naprawdę docierają Twoje testy, warto było zrobić to porządnie: 53 z 54 plików źródłowych mają 100% instrukcji, gałęzi, funkcji i wierszy, a ostatni — warstwa łącząca z VS Code — 95% funkcji. Pisanie testów ujawniło opisane wyżej błędy, a do tego ponad dwadzieścia zabezpieczeń, które nigdy nie mogły się wykonać: ścieżki awaryjne stojące za warunkami, które już je wykluczyły, wyglądające jak siatki bezpieczeństwa, choć niczego nie łapały. Zostały usunięte, a nie zamaskowane testem, który nie mógł zawieść.
0.2025.17 — Zapytane w chwili wartej odpowiedzi
2024-04-27
Zmieniono
- Opcjonalna ankieta czeka teraz, aż naprawdę użyjesz rozszerzenia, i pyta w lepszym momencie. Liczyła dni kalendarzowe od instalacji, mierząc, jak dawno je zainstalowano, a nie czy kiedykolwiek widziano je w działaniu — instalacja nietknięta przez miesiąc dostawała prośbę o ocenę produktu, który nic jej nie pokazał. Teraz oprócz upływu czasu potrzebne są rzeczywiste wczytania pokrycia, a ankieta nie pojawia się już podczas uruchamiania edytora: czeka na udane wczytanie. Po roku przychodzi trzecie i ostatnie zaproszenie, bo dwa w jednym kwartale trwale wykluczały każdego, kto akurat był zajęty.
- Tłumaczenie niderlandzkie nie jest już formalne. Wszędzie zwracało się przez «u», co dla narzędzia programisty brzmi sztywno i nie pasowało do reszty głosu produktu. Wszystkie niderlandzkie teksty używają teraz «je» — przepisane zdanie po zdaniu, bo zmiana pociąga za sobą formy czasowników.
0.2025.16 — Kod, nie firma
2024-04-23
Zmieniono
- Formularz aktywacji pytał samodzielnych programistów o „company code”. Kupując Pro lub Pro Plus jako jedna osoba, otrzymujesz kod z własnej subskrypcji — nie stoi za nim żadna firma, a pytanie o nią sugeruje pomyłkę co do formularza. To pole nazywa się teraz Subscription code dla Pro i Pro Plus, a pozostaje Company code dla Business i Enterprise, gdzie zespół faktycznie dzieli jeden kod. Podpowiedzi poniżej były już pisane osobno dla każdego planu; ogólna została tylko etykieta.
0.2025.15 · build 3 — Mierzone według tego, co ustawiłeś
2024-03-25
Naprawiono
- Wygenerowany raport HTML oceniał kod względem 100%, niezależnie od ustawionych progów. Kolumna Status sprawdzała każdą metrykę wobec ukrytej setki, więc projekt, który ustawił progi na 80 i je spełnił, widział zielony baner COMPLIANT tuż nad kolumną czerwonych krzyżyków — dla tego samego przebiegu, na tej samej stronie. Legenda metryk robiła to samo. Obie korzystają teraz z ustawionych progów, a tam gdzie żaden nie obowiązuje, pokazują wyszarzoną kreskę zamiast zmyślonego werdyktu.
- Baner zgodności twierdził więcej, niż sprawdził. Zawsze głosił „spełniono wszystkie ustawione progi", także w trybie domyślnym, który bada wyłącznie wynik ważony — przebieg mógł więc twierdzić, że spełniono każdy próg, podczas gdy jeden wyraźnie zawodził w tabeli poniżej. Każdy tryb podaje teraz regułę, którą faktycznie zastosował.
- README twierdził, że rozszerzenie „działa bezpłatnie do 2026-12-31". Taka data nie istnieje w produkcie. Wcześniejsze wydanie poprawiło to zdanie w opisach ustawień, ale pominęło README — pierwszą rzecz czytaną w Marketplace. Teraz opisuje, co dzieje się naprawdę: 14 dni próbnych od pierwszego użycia, potem darmowy poziom Community, bez daty, po której cokolwiek przestaje działać.
0.2025.14 — Odróżnić je
2024-03-15
Zmieniono
- Obie edycje nie wyglądają już identycznie w Marketplace. Pro i Community budowane są z jednego drzewa źródeł, a do tej pory dotyczyło to także ikony — więc obie pozycje były tym samym obrazkiem z innym podpisem, obok siebie w tych samych wynikach wyszukiwania. Teraz każda edycja ma własną: tę samą grafikę z kolorowym pasem u dołu, turkusowym dla Pro i łupkowym dla Community. Słowo odróżnia je, gdy ikona jest pokazana w dużym rozmiarze; w wierszu wyników wyszukiwania słowo jest zbyt małe, by je przeczytać, więc rolę tę przejmuje kolor.
0.2025.13 — Dostępne stamtąd, gdzie stoisz
2024-02-26
Naprawiono
- Otwarcie widoku z adnotacjami nie blokuje już otwarcia go ponownie. Panel źródła z adnotacjami to widok internetowy, a nie edytor tekstu, więc dopóki miał fokus, rozszerzenie nie widziało „bieżącego pliku" — a Open Annotated Source odpowiadał tam „otwórz najpierw plik z wczytanym pokryciem", komuś, kto patrzył właśnie na widok pliku, który pokrycie wyraźnie ma. Teraz sięga po plik stojący za panelem, na który patrzysz. Ten sam blok po cichu pomijał także ponowne sprawdzenie, dla którego drugie uruchomienie w ogóle istnieje: gdy skonfigurowany jest raport HTML llvm-cov, to właśnie ponowne uruchomienie przełącza panel na stronę tego raportu — jeśli więc kompilacja pokrycia kończyła się po otwarciu panelu, nie dało się jej stamtąd odebrać.
0.2025.12 · build 2 — Mówić to, co prawdziwe
2024-02-15
Dodano
- Płatna subskrypcja Pro odnawia się teraz sama. Każdy klucz aktywacyjny działa dokładnie tyle, ile wynosi opłacony okres. Plany zespołowe odbierają odnowiony okres przy następnym kontakcie, ale indywidualny Pro nigdy się nie łączy — działa w pełni offline — więc nic mu tego odnowienia nie dostarczało, a klucz abonenta miesięcznego wygasałby mniej więcej co miesiąc, choćby płacił najsumienniej. Rozszerzenie prosi teraz po cichu o nowy klucz, wyłącznie w dniach wokół własnego wygaśnięcia i tylko wtedy, gdy ma kod potwierdzający opłaconą subskrypcję. Bycie offline w tym oknie nic nie kosztuje: klucz działa do faktycznego wygaśnięcia, a kolejna próba po nim go przywraca.
- Aktywacja z e-maila o zakupie to jedno kliknięcie. Link przekazuje rozszerzeniu plan i kod bezpośrednio, zamiast otwierania VS Code, szukania polecenia i ręcznego wklejania kodu. Przed zajęciem stanowiska zawsze pyta o potwierdzenie. Ręczne wpisanie kodu działa dokładnie jak wcześniej — link to skrót, nigdy jedyna droga — i działa też w wydaniu Community.
Naprawiono
- Opis jednego z ustawień twierdził, że rozszerzenie jest "bezpłatne do 2026-12-31". Takiej daty nie ma nigdzie w produkcie. W rzeczywistości jest 14-dniowy okres próbny liczony od pierwszego użycia, po którym rozszerzenie wraca na bezpłatny poziom Community. Teraz właśnie to tam napisano, w każdym języku.
- Ustawienia progów nie podają już wydania, w którym zmieniły się ich wartości domyślne — numer wersji w środku zdania odpowiada na pytanie, którego nikt czytający opis ustawienia nie zadaje.
- Kilka przetłumaczonych opisów wskazywało polecenie, którego żaden przetłumaczony VS Code nie pokazuje. Odwoływały się do polecenia aktywacji jego angielską nazwą, więc każdy, kto nie pracuje po angielsku, szukał w palecie poleceń tekstu, którego tam nie ma.
0.2025.11 · build 3 — Liczy się to, co się liczy
2023-12-26
Naprawiono
- Projekt bez decyzji MC/DC mógł pokazywać 0% pokrycia całkowitego. Niektóre narzędzia zgłaszają sekcję MC/DC nawet wtedy, gdy nie ma w niej nic do zmierzenia, a było to odczytywane jako „0% pokrycia” zamiast „nie ma czego pokrywać”. Ponieważ wynik ogólny spada do zera, gdy tylko jakakolwiek metryka wynosi zero, w pełni pokryty projekt mógł pokazywać 0%. Metryka, w której nie ma czego mierzyć, nie wchodzi już w ogóle do wyniku, a jej wiersz znika zamiast pojawiać się jako „0 / 0 warunków pokrytych”.
- Status licencji jest teraz przetłumaczony na wszystkie 17 języków. Wszędzie pozostawał po angielsku, a ponieważ pojawia się wewnątrz zdań, które były już przetłumaczone, dawało to w połowie przetłumaczony wiersz na pasku stanu, w powiadomieniach i w panelu pokrytych plików.
- Widok Kod z adnotacjami oraz podpowiedzi o pokryciu również zostały przetłumaczone — tabela szczegółów zgodności, przyciski nawigacji wraz z podpowiedziami oraz szczegóły gałęzi i MC/DC.
Zmieniono
- Płatną subskrypcję Pro można teraz aktywować własnym kodem. Lista planów we wniosku o klucz zyskała pozycję Pro, więc kod dołączany do subskrypcji Pro ma wreszcie gdzie zostać wpisany. Indywidualne klucze Pro nadal działają całkowicie offline i po aktywacji nigdy nie łączą się z serwerem.
- Ikona na pasku aktywności jest większa i lepiej widoczna obok wbudowanych ikon.
- Przejście na edycję Community instaluje ją teraz z fucini.software. Wcześniej próbowano przez Marketplace, gdzie edycja Community nie jest opublikowana, więc przełączenie mogło zostawić Cię bez żadnego zainstalowanego rozszerzenia.
0.2025.10 · build 5 — Łagodniejsze lądowanie
2023-12-08
Zmieniono
- Wygasła subskrypcja przechodzi teraz na bezpłatny poziom — gdy indywidualny klucz aktywacyjny się kończył, rozszerzenie w nieskończoność prosiło o odnowienie. Rezygnacja z odnowienia to normalne zakończenie subskrypcji, a nie usterka, więc rozszerzenie przechodzi teraz zamiast tego na stały, bezpłatny poziom Community. Plany zespołowe celowo pozostają bez zmian: wygasły klucz Pro Plus, Business lub Enterprise nadal jest zgłaszany jako wygasły, ponieważ tam odnowić go musi administrator, a ciche przeniesienie całej firmy na bezpłatny poziom by to ukryło.
Naprawiono
- Wyłączenie telemetrii jest teraz respektowane w każdym przypadku. Jedna ścieżka w kodzie mogła pominąć tę kontrolę, gdy włączony był wewnętrzny tryb szczegółowej diagnostyki rozszerzenia. Tryb ten jest wyłączony w każdej opublikowanej kompilacji, więc żadne wydanie nigdy nie zachowywało się w ten sposób, ale kontrola jest teraz bezwarunkowa.
- Ustawienia działają natychmiast, zamiast czekać na ponowne wczytanie. Zmiana przemapowania ścieżek, wykluczania komentarzy, filtrowania według git-diff lub sum dla wykluczonych plików powoduje teraz natychmiastowe ponowne wczytanie pokrycia — zwłaszcza przemapowanie ścieżek, bo po to właśnie ustawienie sięgasz wtedy, gdy ścieżki się nie zgadzają.
- „Unlock Full Features” i „Switch to Community” mogły zatrzymać się w połowie bez żadnego komunikatu. Obie operacje wykonują się teraz do końca.
- Twój klucz aktywacyjny pozostaje powiązany z tą samą tożsamością maszyny. W niektórych konfiguracjach tożsamość ta mogła wcześniej być generowana na nowo między sesjami, co unieważniało już wydany klucz.
0.2025.9 — Kompletne tłumaczenia
2023-12-02
Dodano
- Kompletne tłumaczenia we wszystkich 17 dostarczanych językach — około stu nowszych ciągów interfejsu, w tym okna aktywacji i licencjonowania, opcjonalna ankieta zwrotna, proces odblokowania Community oraz powiadomienia o samoaktualizacji, wciąż wracało do angielskiego w każdym pakiecie innym niż angielski. Wszystkie 17 języków obejmuje teraz pełny interfejs działania rozszerzenia.
Zmieniono
- Przegląd porządkowy komentarzy w kodzie źródłowym, dokumentacji skryptów budowania oraz listy plików do pakowania. Zestaw plików dostarczanych w rozszerzeniu pozostaje bez zmian; brak zmian funkcjonalnych i behawioralnych.
0.2025.8 — Edycje nie mogą już kolidować
2023-11-20
Naprawiono
- Zainstalowanie jednocześnie edycji Pro i Community mogło spowodować awarię jednej z nich przy starcie — rejestrują te same polecenia i ten sam widok plików pokrycia. Teraz jest to wykrywane od razu: jeśli druga edycja też jest zainstalowana, aktywacja zatrzymuje się czysto, z komunikatem proszącym o odinstalowanie jednej z nich, zamiast niewyjaśnionego niepowodzenia aktywacji.
0.2025.7 — Porządki
2023-10-30
Wydanie porządkowe; bez zmian funkcjonalnych.
0.2024.6 — Poziom Community i plany zespołowe
2023-10-17
Stały bezpłatny poziom, plany zespołowe współdzielące pulę stanowisk oraz osobna edycja Community rozszerzenia.
Dodano
- Stały, bezpłatny poziom Community — zamiast twardego zatrzymania po zakończeniu 14-dniowego okresu próbnego rozszerzenie przechodzi teraz w tryb Community: wszystkie funkcje poza MC/DC, ograniczona miesięczna próbka Full HTML Report i trwałych widoków Annotated Source, hojne dzienne limity dla kilku automatyzowalnych akcji, a wszystko pozostałe bez ograniczeń.
- Odblokuj wszystkie funkcje za darmo — nowe polecenie „Unlock Full Features” wymienia szczegółową telemetrię użycia na pełne, nieograniczone uprawnienia, odwracalne w każdej chwili. Opcjonalna ankieta zwrotna w rozszerzeniu daje w zamian 30-dniowy klucz z pełnią funkcji, bez żadnych zobowiązań.
- Plany zespołowe: Pro Plus, Business i Enterprise — współdzielą one pulę stanowisk (kod firmy plus liczba stanowisk) zamiast jednego klucza na maszynę, a działające w tle meldowanie utrzymuje uprawnienia stanowiska aktualne i automatycznie sygnalizuje stanowisko cofnięte lub ograniczone.
- Fucini Coverage Studio Community — osobna, dedykowana pozycja zbudowana z tego samego źródła, w której kod okresu próbnego/aktywacji/planów zespołowych jest faktycznie nieobecny, a nie tylko ukryty. Zobacz stronę pobierania.
Zmieniono
- Generowanie Full HTML Report oraz trwałe widoki Annotated Source (zwykły i obok siebie) są teraz w bazowym zestawie Community funkcjami płatnego poziomu — pozostaje tylko przełączany widok w miejscu, limitowany miesięcznie jak dotąd. Odblokowanie nadal daje dostęp do wszystkiego.
- Ostrzeżenie o limicie użycia na poziomie Community proponuje teraz obie drogi naprzód w jednym komunikacie: zobaczyć płatne plany albo odblokować przez telemetrię.
Naprawiono
- Szczegółowa, potencjalnie identyfikująca telemetria (nazwa użytkownika systemu, katalog domowy, parametry CPU/RAM, interfejsy sieciowe oraz pełna treść raportu/kodu źródłowego) może być teraz wysyłana wyłącznie przez Community lub bezpłatne uprawnienia uzależnione od telemetrii — nigdy przez płatną licencję Pro/Pro Plus/Business/Enterprise, niezależnie od lokalnych ustawień telemetrii.
- Instalacja działająca już na wcześniejszej wersji nie dostaje nowego okresu próbnego tylko dlatego, że została zaktualizowana — teraz poprawnie trafia na poziom Community, jeśli jej poprzedni okres próbny już się skończył.
- Powiadomienie o aktualizacji, postęp pobierania i komunikaty o błędach pokazują teraz zwykłą wersję
Major.Year.Minor (zgodną z tym, co wyświetla widok Extensions w VS Code) zamiast ujawniać wewnętrzny numer builda, np. 0.2024.6 zamiast 0.2024.6.2.
0.2024.5 — Precyzyjnie dostrojone klucze licencyjne
2023-09-03
Klucze aktywacyjne mogą teraz osobno limitować poszczególne funkcje, a administratorzy licencji mogą ręcznie wydać precyzyjnie dostrojony klucz z panelu.
Dodano
- Limity użycia na funkcję — klucze aktywacyjne mogą teraz limitować każdą funkcję/akcję niezależnie (na przykład eksporty raportu HTML do 1 na miesiąc) zamiast jednego wspólnego limitu wczytań pokrycia. Istniejące klucze działają bez zmian.
- Ręczne wydawanie kluczy — administratorzy licencji mogą teraz ręcznie wydać klucz dla kodu żądania otrzymanego poza ankietą w edytorze, wybierając dokładnie, które funkcje przyznać, termin ważności oraz limity dla poszczególnych funkcji; klucz jest wysyłany e-mailem automatycznie, gdy podano adres.
0.2024.4 — Niezawodność kanału aktualizacji
2023-07-24
Naprawia błąd buforowania, który mógł ukrywać nowe wydania przed użytkownikami za niektórymi firmowymi serwerami proxy.
Naprawiono
- Niezawodność kanału samoaktualizacji — manifest aktualizacji jest teraz serwowany ze ścisłym nagłówkiem no-cache, więc buforujący serwer proxy między fucini.software a odbiorcą nie może już podać nieaktualnej kopii ukrywającej nowe wydania.
0.2024.3 — Drobne poprawki i wydajność
2023-07-13
Niewielkie wydanie konserwacyjne: kilka drobnych poprawek błędów i usprawnień wydajności.
Naprawiono
- Poprawki błędów — drobne poprawki błędów i usprawnienia stabilności.
- Wydajność — niewielkie usprawnienia wydajności podczas wczytywania i renderowania pokrycia.
0.2024.2 — Automatyczna aktywacja
2023-06-20
Klucze aktywacyjne są teraz wydawane i stosowane automatycznie — koniec czekania na e-mail.
Wydanie ewaluacyjne. Każda instalacja otrzymuje bezpłatny 14-dniowy okres próbny z odblokowanymi wszystkimi funkcjami, liczony od pierwszego użycia; potem przechodzi na bezpłatny poziom Community, zamiast przestać działać. Klucz licencyjny jest wydawany automatycznie na żądanie. Dowiedz się więcej →
Zmieniono
- Automatyczna aktywacja — prośba o klucz wysyła teraz krótką ankietę i automatycznie stosuje otrzymany klucz w ustawieniach, bez wymiany e-maili.
- Szybsze odnowienia — prośba o odnowienie zadaje jedynie pytania dotyczące użytkowania i życzeń; dane kontaktowe z poprzedniej prośby są ponownie wykorzystywane, nigdy nie są proszone ponownie.
- Stałe okno oceny — okres próbny trwa teraz dla wszystkich do 31.12.2026, zastępując poprzednie 14-dniowe odliczanie od instalacji.
- Zlokalizowany proces aktywacji — kwestionariusz odnowienia i potwierdzenia aktywacji są teraz przetłumaczone na wszystkie 18 obsługiwanych języków, tak samo jak reszta rozszerzenia.
0.2024.1 · build 3 — Inteligentniejsze sprawdzanie aktualizacji
2023-06-02
Rozszerzenie sprawdza teraz aktualizacje zarówno na fucini.software, jak i w VS Code Marketplace, zawsze oferując nowszą wersję.
Naprawiono
- Sprawdzanie z dwóch źródeł — teraz odpytuje zarówno fucini.software, jak i VS Code Marketplace, oferując nowszą wersję.
0.2024.0 — Wydanie początkowe
2023-04-26
Pierwsze publiczne wydanie Fucini Coverage Studio — natywne pokrycie kodu dla VS Code, które wczytuje pliki śledzenia standardów branżowych, normalizuje je do jednego kanonicznego modelu, deterministycznie łączy przebiegi i raportuje poprzez wbudowane Test Coverage API VS Code.
Dodano
- Wczytywanie wielu formatów — LCOV, llvm-cov JSON, Cobertura XML, JaCoCo XML, Istanbul/nyc i SimpleCov JSON, wykrywane automatycznie.
- Deterministyczne łączenie — kilka plików śledzenia połączonych w jeden przebieg z zapisanym pochodzeniem, stabilne niezależnie od kolejności wczytywania.
- Natywny interfejs pokrycia — wskaźniki wierszy/gałęzi/funkcji, linijka przeglądu i wbudowany panel Test Coverage.
- Pokrycie MC/DC — podział na decyzje po najechaniu kursorem oraz opcjonalny kolorowy wskaźnik marginesu.
- Wynik złożony — ważona wagami SIL średnia harmoniczna dla wierszy, gałęzi, funkcji, regionów, MC/DC i instancjacji C++.
- Werdykt zgodności — kontrola COMPLIANT / NON-COMPLIANT z trybami
strict, whm, both i either.
- Przemapowanie ścieżek, pokrycie różnicowe, odznaki Explorer oraz globalny pasek stanu.
- Analiza w edytorze — CodeLens funkcji, podpowiedzi po najechaniu na gałąź, ostrzeżenia o martwym kodzie, ostrzeżenia o nieaktualnym pokryciu oraz Next/Previous Uncovered.
- Widok pokrytych plików, raporty HTML, historia i trendy, tryb obserwacji oraz eksport Fucini JSON.