Recettes de couverture

Fucini Coverage Studio est basé sur le format, pas sur le langage : tout langage dont la chaîne d'outils peut produire l'un des vingt-cinq formats pris en charge fonctionne. Ci-dessous, une recette concrète par compilateur. Les commandes sont dans des blocs <pre> — copiez-les telles quelles et adaptez les noms/chemins à votre projet.

Swift llvm-cov JSON

Swift utilise LLVM en interne, vous exportez donc du JSON avec llvm-cov export --format=json depuis le binaire de test et son profil fusionné.

# 1. Run tests with coverage (Swift Package Manager)
swift test --enable-code-coverage

# 2. Resolve the profdata and test-binary paths
PROF=$(swift build --show-bin-path)/codecov/default.profdata
BIN=$(swift build --show-bin-path)/<PackageName>PackageTests.xctest/Contents/MacOS/<PackageName>PackageTests
# Linux: BIN=$(swift build --show-bin-path)/<PackageName>PackageTests.xctest

# 3. Export JSON
xcrun llvm-cov export "$BIN" -instr-profile "$PROF" -format=json > coverage.json
# Linux (no xcrun): llvm-cov export "$BIN" -instr-profile "$PROF" -format=json > coverage.json

Projets Xcode : compilez avec xcodebuild test -enableCodeCoverage YES -derivedDataPath ./DerivedData, puis trouvez le .profdata et le binaire de l'app sous DerivedData et exécutez le même llvm-cov export.

Swift / Objective-C — Xcode report xccov JSON

The shortest path from an .xcresult: no profdata hunting, no binary paths, one command. Use it when you want percentages and per-function coverage quickly.

# 1. Run the tests
xcodebuild test -scheme MyApp -enableCodeCoverage YES -derivedDataPath ./DerivedData

# 2. Export the coverage report from the .xcresult
xcrun xccov view --report --json \
  ./DerivedData/Logs/Test/*.xcresult > coverage.json

Gutters stay empty for this format, by design. xccov reports how many of a file's lines are executable and how many were covered, but not which — that answer needs one xccov view --file run per file. Studio will not invent the missing line numbers, because an invented gutter is indistinguishable from a measured one. You get file percentages, per-function execution counts, CodeLens and the worst-covered rankings. For line-by-line highlighting, use the llvm-cov route above against the same build, or slather for Cobertura.

C / C++ — Clang / LLVM llvm-cov JSON

L'entrée la plus riche : couverture des instructions, branches, fonctions, régions, MC/DC et instanciations de templates C++. Recommandé pour C/C++.

# 1. Compile with instrumentation (add -fcoverage-mcdc on Clang 18+ for MC/DC)
clang++ -fprofile-instr-generate -fcoverage-mapping -o app main.cpp

# 2. Run the instrumented binary
LLVM_PROFILE_FILE="app.profraw" ./app

# 3. Merge raw profiles
llvm-profdata merge -sparse app.profraw -o app.profdata

# 4. Export JSON
llvm-cov export ./app -instr-profile=app.profdata -format=json > coverage.json

C / C++ — GCC LCOV / gcov JSON

GCC produit des données .gcda/.gcno que lcov (ou gcovr) transforme en lcov.info. Le JSON que gcov et gcovr écrivent eux-mêmes est lu aussi, ce qui supprime entièrement l'étape de conversion — notez que gcov --json-format compresse sa sortie en gzip sauf si vous passez --stdout.

# 1. Compile with coverage flags (--coverage == -fprofile-arcs -ftest-coverage)
gcc --coverage -O0 -o app main.c

# 2. Run the binary (writes .gcda next to .gcno)
./app

# 3. Capture lcov.info and drop system/test files
lcov --capture --directory . --output-file lcov.info
lcov --remove lcov.info '/usr/*' '*/test/*' --output-file lcov.info

# Alternative: no conversion at all — native JSON
# gcovr --json coverage.json
# gcov --json-format --stdout app.gcda > coverage.json

# Alternative: gcovr straight to Cobertura or lcov
# gcovr --lcov lcov.info
# gcovr --cobertura coverage.xml

Utilisez le gcov correspondant à votre version de GCC (par ex. gcov-13 avec gcc-13), sinon le .gcda aura une incompatibilité de version.

Rust LCOV / llvm-cov JSON

Le plus simple avec cargo-llvm-cov (cargo install cargo-llvm-cov), qui pilote l'instrumentation LLVM de Rust pour vous.

# LCOV
cargo llvm-cov --lcov --output-path lcov.info

# llvm-cov JSON (richer metrics)
cargo llvm-cov --json --output-path coverage.json

# Manual, without cargo-llvm-cov:
# RUSTFLAGS="-C instrument-coverage" cargo test
# llvm-profdata merge -sparse default_*.profraw -o cov.profdata
# llvm-cov export target/debug/<testbin> -instr-profile=cov.profdata -format=json > coverage.json

Go Go coverage profile

Le profil natif de Go est lu directement — aucune étape de conversion. coverage.out fait aussi partie des noms recherchés par la détection : un projet Go n'a donc besoin d'aucune configuration.

# Run tests with a coverage profile — that is the whole recipe
go test ./... -coverprofile=coverage.out

# Converting still works if your pipeline already does it:
# go install github.com/jandelgado/gcov2lcov@latest
# gcov2lcov -infile=coverage.out -outfile=lcov.info

Python coverage.py JSON

Utilisez coverage.py (ou pytest-cov) et produisez son JSON natif. Préférez-le à l'export Cobertura : seul le JSON consigne les lignes qu'un # pragma: no cover a exclues, et Studio conserve cette distinction au lieu de compter ces lignes comme couvertes ou comme manquantes.

# coverage.py — native JSON (recommended)
coverage run --branch -m pytest
coverage json           # -> coverage.json

# The Cobertura export still works
coverage xml            # -> coverage.xml (Cobertura)

# or pytest-cov in one step
pytest --cov=my_package --cov-report=xml

Java / Kotlin JaCoCo XML

JaCoCo produit le rapport XML que Studio lit — assurez-vous que le format XML est activé (le rapport HTML n'est pas lu).

# Maven (jacoco-maven-plugin configured, XML format on)
mvn test
# -> target/site/jacoco/jacoco.xml

# Gradle
# build.gradle: jacocoTestReport { reports { xml.required = true } }
./gradlew test jacocoTestReport
# -> build/reports/jacoco/test/jacocoTestReport.xml

JavaScript / TypeScript Istanbul / nyc

Istanbul (via nyc, Jest ou Vitest) produit coverage-final.json. Ses rapporteurs Clover et Cobertura sont lus également — Vitest écrit du Clover par défaut, donc un projet Vitest possède souvent déjà un fichier que Studio sait ouvrir.

# nyc
npx nyc --reporter=json mocha           # -> coverage/coverage-final.json

# Jest (Istanbul built in)
jest --coverage --coverageReporters=json

# Vitest
vitest run --coverage --coverage.reporter=json

# Clover      --coverageReporters=clover     (-> coverage/clover.xml)
# Cobertura   --coverageReporters=cobertura  (-> cobertura-coverage.xml)

.NET / C# OpenCover / Cobertura XML

Collectez la couverture avec coverlet pendant dotnet test. Ses deux formats XML sont lus ; préférez OpenCover, qui consigne un compteur pour chaque branche d'un branchement, là où Cobertura indique seulement combien de branches ont été couvertes.

# OpenCover — keeps per-arm branch counts (recommended)
dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover
# -> coverage.opencover.xml

# Cobertura, via Coverlet's data collector
dotnet test --collect:"XPlat Code Coverage"
# -> TestResults/<guid>/coverage.cobertura.xml

PHP Clover XML

Lancez PHPUnit avec Xdebug ou PCOV comme pilote de couverture et écrivez du Clover — le format que php-code-coverage produit par défaut, et celui que la plupart des projets ont déjà configuré. Cobertura est lu aussi, si votre pipeline émet plutôt cela.

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

# phpunit.xml alternative:
# <coverage><report><clover outputFile="clover.xml"/></report></coverage>

# Cobertura also works:
# XDEBUG_MODE=coverage phpunit --coverage-cobertura coverage.xml

Ruby SimpleCov

Configurez le formateur JSON de SimpleCov (gem 'simplecov-json') pour qu'un coverage.json lisible par machine soit écrit.

# test_helper.rb / spec_helper.rb (before loading your code)
require 'simplecov'
require 'simplecov-json'
SimpleCov.formatter = SimpleCov::Formatter::JSONFormatter
SimpleCov.start

# then run your tests normally
rake test        # or: rspec
# -> coverage/coverage.json  (or .resultset.json)

Ada — GNATcoverage GNATcov XML

The format DO-178C and EN 50128 teams actually produce. --annotate=xml writes a directory, not a file: load the per-source *.xml files, several at once if you like.

# 1. Instrument and build
gnatcov instrument --level=stmt+mcdc --projects my_project.gpr
gprbuild -P my_project.gpr --src-subdirs=gnatcov-instr --implicit-with=gnatcov_rts

# 2. Run, then produce XML
gnatcov coverage --level=stmt+mcdc --annotate=xml \
  --output-dir=coverage/ my_project.gpr obj/my_program.srctrace
# -> coverage/*.xml  (one per source; index.xml is just a directory listing)

A partially covered line (!) stays a covered line with an uncovered decision — the shortfall appears in branch and MC/DC coverage, where it belongs, rather than being written off as an uncovered line. pragma Annotate (Xcov, Exempt_On) regions become excluded lines. With --level=stmt+mcdc, MC/DC drives the compliance gate and the composite score.

C / C++ — BullseyeCoverage Bullseye XML

The commercial tool most embedded and safety-critical teams already own. Its headline metric is condition/decision coverage rather than line coverage, and Studio keeps the two separate rather than blending them.

# 1. Build with the Bullseye compiler wrappers on PATH, then run your tests
cov01 -1                 # enable instrumentation
make && ./run_tests

# 2. Export XML
covxml -f test.cov -o coverage.xml

A single-outcome probe is scored out of one rather than two, so a fully tested switch is not reported as half covered.

.NET — MSTest / vstest Visual Studio .coveragexml

For teams on vstest rather than Coverlet. The binary .coverage file has to be converted first.

dotnet test --collect:"Code Coverage"
dotnet-coverage convert -o coverage.coveragexml TestResults/**/*.coverage

Any language — Coveralls JSON Coveralls

If you already upload to Coveralls, the payload your reporter builds loads here directly — line-level, so gutters work. Reporters exist for most ecosystems: coveralls-lcov, excoveralls (Elixir), coveralls-python, simplecov-coveralls (Ruby), goveralls (Go), cargo-tarpaulin --out Coveralls (Rust) and node-coveralls.

# Example: Elixir, writing the payload instead of posting it
MIX_ENV=test mix coveralls.json
# -> cover/excoveralls.json

# Example: Rust
cargo tarpaulin --out Coveralls --output-dir .

A null in the coverage array means the line is not executable — a blank, a comment, a brace — and is excluded from the totals rather than counted as a miss.

Any language — SonarQube generic Generic coverage XML

SonarQube's own hand-written format, for a language with no native tool of its own. Useful mainly when something upstream already emits it.

<coverage version="1">
  <file path="src/a.c">
    <lineToCover lineNumber="5" covered="true"/>
    <lineToCover lineNumber="6" covered="false"/>
  </file>
</coverage>

C / C++ / Ada — VectorCAST VectorCAST XML

VectorCAST writes a Cobertura report with extra attributes attached — mcdcpair-coverage, function-coverage and functioncall-coverage — that plain Cobertura tooling ignores and this reader keeps. No conversion step: point Studio at the report VectorCAST already writes.

# From the VectorCAST GUI or vcast_gui.py, export the Cobertura-format report
# (Environment / Project → Reports → Cobertura), or via the API:
clicast -e <env> report custom Cobertura coverage.xml

The MC/DC pair counts drive the MC/DC gate and composite score exactly as GNATcoverage's do. Function-call coverage is read as its own metric, not folded into branches.

C / C++ — Testwell CTC++ CTC++ text listing

The tool that sits opposite Bullseye in European embedded and safety evaluations, and the one that measures multicondition coverage. Load the execution-profile listing as-is — no conversion, and no trip through Cobertura that would flatten it.

# 1. Instrument and build (per CTC++'s compiler wrapper for your toolchain)
ctc++ gcc -c file.c -o file.o
ctc++ gcc file.o -o app

# 2. Run the instrumented binary (writes MON.sym / MON.dat)
./app

# 3. Produce the text listing
ctcpost --projectfile ctc.proj -m src -t profile.txt

Newer CTC++ installs can skip the listing entirely. ctcpost's LCOV template (-m lcov, where the installed template set includes it) writes LCOV directly, which loads here with no format-specific parsing at all. Use the text listing when only multicondition coverage matters — LCOV has no place for it, and it is reported here as branch coverage rather than as MC/DC, since the two ask different questions.

Any target — Lauterbach TRACE32 TRACE32 XML

The on-chip-trace route: a debugger reports the instruction stream a real target actually executed, with no instrumentation and no probe effect on timing. An export carries exactly one metric — run it once per metric you need, and load all the exports together.

# From a TRACE32 PRACTICE script (.cmm), after a trace-based run:
COVerage.EXPORT.ListModule stmt.xml metric=stmt
COVerage.EXPORT.ListModule mcdc.xml metric=mcdc
COVerage.EXPORT.ListModule func.xml metric=func
COVerage.EXPORT.ListModule call.xml metric=call
COVerage.EXPORT.ListModule object.xml metric=object

stmt becomes line coverage; dec/cond become branch coverage; mcdc drives the MC/DC gate; func and call feed function and function-call coverage; object is the one export that produces object-code coverage. Loading several exports of the same run merges them by module name.

VHDL — GHDL LCOV / gcov JSON

Open-source VHDL simulation already has a way in through GHDL's GCC backend — no dedicated parser needed, because the result is ordinary gcov data.

# 1. Analyse and elaborate with coverage instrumentation
ghdl -a --coverage=stmt,cond your_design.vhd your_testbench.vhd
ghdl -e --coverage=stmt,cond your_testbench

# 2. Run the testbench (writes .gcda next to .gcno)
ghdl -r your_testbench

# 3. Capture as usual
lcov --capture --directory . --output-file lcov.info
# or: gcovr --json coverage.json

For commercial simulators (Riviera-PRO, Active-HDL, QuestaSim), see UCIS/UCDB below instead.

VHDL / Verilog / SystemVerilog — UCIS / Aldec UCDB UCIS / UCDB XML

Two documents answer to this name; load whichever your simulator writes. Statement and branch coverage come across — toggle, FSM, assertion and functional coverage are HDL-specific concepts with no equivalent metric here, and are not read.

# Accellera-standard UCIS interchange (Questa, VCS, Xcelium — consult your
# simulator's manual for the exact export command, typically via its GUI
# or a `ucis` command-line utility)

# Aldec Riviera-PRO / Active-HDL — native .ucdb converted to UCIS XML
acdb2xml -i coverage.ucdb -o coverage.xml

Beckhoff TwinCAT 3 Visual Studio .coveragexml

TwinCAT 3's C++ modules compile with MSVC inside Visual Studio, so ordinary .NET/C++ coverage tooling already applies — see MSTest/vstest above, or OpenCppCoverage for an instrumentation-free alternative. The Structured Text (ST) half has no coverage tool at all, from Beckhoff or any third party; if your project is ST-only, there is currently nothing to load here.

# OpenCppCoverage against a TwinCAT C++ module's unit tests
OpenCppCoverage.exe --sources=MyModule --export_type=cobertura:coverage.xml -- MyModuleTests.exe

Simulink SonarQube generic coverage

Simulink Coverage's own report has no format this extension reads directly. A short MATLAB script walking the cvdata object produced by cvsim or cvload can write SonarQube's generic coverage XML, which is four attributes on two elements — well within reach of a project's own build script.

% Sketch: iterate cvdata's per-line decision/condition results and
% write <coverage version="1"><file path="..."><lineToCover .../>
% See the SonarQube example in the table above for the exact schema.
cv_data = cvload('model_cvdata.cvt');
% ... walk cv_data.get('metric_summary') per model block ...

CODESYS Not supported

CODESYS's own Profiler cannot say which statements ran — only how much time a POU spent — and its counters live in the runtime's RAM, clearing on a warm reset with no export this extension could read. If your PLC toolchain is Siemens instead, TIA Portal exports coverage data through its own test-management tooling that can be converted to SonarQube's generic format the same way as Simulink above.

.NET / C# — NCover NCover XML

NCover's Coverage.xml outlived the tool itself: a decade of build scripts and other coverage tools still write or consume this schema. Load it as-is, no conversion needed.

NCover.Console.exe //x Coverage.xml -- dotnet test

.NET / C# — JetBrains dotCover dotCover DetailedXML

The report type matters. dotCover's plain Xml report is a rollup with no line numbers at all; ask for DetailedXml specifically.

dotnet dotcover.dll cover --Output=dotCover.dcvr --TargetExecutable=dotnet --TargetArguments="test"
dotnet dotcover.dll report --Source=dotCover.dcvr --Output=dotCover.xml --ReportType=DetailedXML

JetBrains deprecated DetailedXml in dotCover 2025.2 — check your installed version's documentation for the current flag spelling if this one is rejected.

Delphi / Object Pascal & legacy Java — EMMA EMMA XML

Delphi has no lcov, no Cobertura, nothing else this extension reads — DelphiCodeCoverage is the way in. The same schema is also what a good deal of older Java tooling still emits.

# DelphiCodeCoverage, with per-line hit counts (needed for gutters)
DelphiCodeCoverage.exe -e MyApp.exe -m MyApp.map -xml -xmllines -o coverage.xml

Without -xmllines the report is a rollup percentage only — Studio shows a file summary and no gutters for it, the same treatment Xcode's xccov gets, rather than guessing which lines ran.

Any language — PIT / Stryker Mutation reports

Mutation testing answers a question coverage cannot: not whether a line ran, but whether anything failed when it was changed. Load the report beside a real coverage tracefile — the two merge by path, and the mutation score appears as its own metric, never averaged into the composite score.

# PIT — Java, Kotlin, Scala
mvn org.pitest:pitest-maven:mutationCoverage
# -> target/pit-reports/<timestamp>/mutations.xml

# Stryker — JavaScript, TypeScript, C#, Scala
npx stryker run
# -> reports/mutation/mutation.json (rename or point discovery at it)

Already covered, with no work at all

A few ecosystems reach Studio through a format it already reads, so there is nothing extra to install or configure:

• Rust — cargo llvm-cov --lcov or grcov both emit LCOV; cargo llvm-cov --json emits llvm-cov JSON.
• Kotlin — Kover writes JaCoCo XML.
• Dart / Flutter — flutter test --coverage writes coverage/lcov.info.
• PHP — PHPUnit's --coverage-clover is Clover XML.
• Qt / Squish Coco — exports Cobertura or LCOV.
• Erlang — rebar3 cover converts to Cobertura via covertool.
• Elixir — excoveralls writes Coveralls JSON directly (mix coveralls.json).
• Haskell — hpc coverage converts to Cobertura or LCOV via hpc-lcov.
• Perl — Devel::Cover's -report clover writes Clover XML.
• R — the covr package's to_cobertura() writes Cobertura XML.
• Julia — Coverage.jl's LCOV.writefile writes LCOV directly.
• Fortran — GCC-based (gfortran --coverage) goes through gcov/lcov like C.
• PL/SQL — Oracle's DBMS_PLSQL_CODE_COVERAGE exports convert to Cobertura via community tooling (e.g. plsql-cover).

Charger le résultat dans Studio

1. Placez le fichier de couverture dans votre espace de travail (par ex. la racine du projet).
2. Palette de commandes → Fucini Coverage: Load Coverage — ou laissez watch.enabled activé (par défaut) et il se charge automatiquement.
3. Ouvrez un fichier source couvert : les lignes couvertes obtiennent une marque verte avec un compteur, les non couvertes en rouge, et la vue Covered Files se remplit.

Conseils généraux (tous langages)

• Compilez/testez avec les optimisations désactivées (-O0) pour un mappage source-couverture 1:1 ; les optimiseurs peuvent fusionner ou supprimer des lignes.
• Filtrez toujours le code tiers/de test (options ignore/remove) afin de ne pas fausser le score composite.
• Plusieurs fichiers ? Chargez-les tous — Studio les fusionne de manière déterministe en une exécution avec provenance enregistrée.
• Si les chemins CI diffèrent de votre checkout, utilisez le remappage de chemins fuciniCoverage (voir Guide utilisateur §7).