Receitas de cobertura

O Fucini Coverage Studio é baseado no formato, não na linguagem: funciona qualquer linguagem cuja cadeia de ferramentas consiga emitir um dos vinte e cinco formatos suportados. Abaixo, uma receita concreta por compilador. Os comandos estão em blocos <pre> — copie-os tal como estão e ajuste nomes/caminhos ao seu projeto.

Swift llvm-cov JSON

O Swift usa LLVM por baixo, por isso exporta JSON com llvm-cov export --format=json a partir do binário de teste e do seu perfil combinado.

# 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

Projetos Xcode: compile com xcodebuild test -enableCodeCoverage YES -derivedDataPath ./DerivedData, depois encontre o .profdata e o binário da app em DerivedData e execute o mesmo 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

A entrada mais rica: cobertura de instruções, ramos, funções, regiões, MC/DC e instanciações de templates C++. Recomendado para 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

O GCC emite dados .gcda/.gcno que o lcov (ou o gcovr) transforma num lcov.info. O JSON que o gcov e o gcovr escrevem por si também é lido, o que dispensa por completo o passo de conversão — note que o gcov --json-format comprime a saída com gzip a menos que passe --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

Use o gcov correspondente à sua versão do GCC (por ex. gcov-13 com gcc-13), caso contrário o .gcda terá incompatibilidade de versão.

Rust LCOV / llvm-cov JSON

Mais fácil com cargo-llvm-cov (cargo install cargo-llvm-cov), que controla a instrumentação LLVM do Rust por si.

# 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

O perfil nativo do Go é lido diretamente — sem passo de conversão. coverage.out é também um dos nomes que a deteção procura, pelo que um projeto em Go não precisa de configuração alguma.

# 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

Use coverage.py (ou pytest-cov) e emita o seu JSON nativo. Prefira-o à exportação Cobertura: só o JSON regista que linhas um # pragma: no cover excluiu, e o Studio mantém essa distinção em vez de as contar como cobertas ou como em falta.

# 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

O JaCoCo produz o relatório XML que o Studio lê — garanta que o formato XML está ativado (o relatório HTML não é lido).

# 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

O Istanbul (via nyc, Jest ou Vitest) emite coverage-final.json. Os seus relatores Clover e Cobertura também são lidos — o Vitest escreve Clover por omissão, pelo que um projeto Vitest já costuma ter um ficheiro que o Studio consegue abrir.

# 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

Recolha a cobertura com coverlet durante o dotnet test. Ambos os seus formatos XML são lidos; prefira OpenCover, que regista uma contagem por cada ramo de uma ramificação, ao passo que o Cobertura apenas indica quantos ramos foram cobertos.

# 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

Execute o PHPUnit com Xdebug ou PCOV como controlador de cobertura e escreva Clover — o formato que o php-code-coverage produz por omissão e o que a maioria dos projetos já tem configurado. Cobertura também é lido, se o seu pipeline emitir isso em vez disso.

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

Configure o formatter JSON do SimpleCov (gem 'simplecov-json') para que seja escrito um coverage.json legível por máquina.

# 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).

Carregar o resultado no Studio

1. Coloque o ficheiro de cobertura no seu workspace (por ex. a raiz do projeto).
2. Paleta de comandos → Fucini Coverage: Load Coverage — ou deixe watch.enabled ativo (predefinido) e carrega automaticamente.
3. Abra um ficheiro-fonte coberto: as linhas cobertas ganham uma marca verde com contagem, as não cobertas a vermelho, e a vista Covered Files preenche-se.

Dicas gerais (todas as linguagens)

• Compile/teste com otimizações desligadas (-O0) para um mapeamento fonte-cobertura 1:1; os otimizadores podem juntar ou remover linhas.
• Filtre sempre o código de terceiros/de teste (flags ignore/remove) para não enviesar a pontuação composta.
• Vários ficheiros? Carregue-os todos — o Studio junta-os de forma determinista numa única execução com proveniência registada.
• Se os caminhos de CI diferirem do seu checkout, use o remapeamento de caminhos fuciniCoverage (ver Guia do utilizador §7).