Skip to content

Bring in test coverage (lcov)

Understand can read your test-coverage results and treat them as metrics — so "which functions and lines did our tests actually exercise?" becomes something you can sort, color, and export alongside complexity and violations. Coverage comes in via Coverage metric plugins, which read the standard lcov .info format produced by gcov/lcov and similar tools.

1. Enable the coverage metrics

There are several coverage metrics available:

Level Metrics
File CoverageLinesFound, CoverageLinesHit, CoverageLinesPercent
File CoverageFunctionsFound, CoverageFunctionsHit, CoverageFunctionsPercent
Function / line CoverageHits — how many times a function or line was executed

To enable them all at once, open the Plugin Manager, filter the list by the Solution: Coverage tag, select the matches, and enable them together.

2. Point it at your coverage file

By default the plugins look for a file named coverage.info in the same directory as your .und project; you can set a different path per project in Project → Configure Project. Generate that .info file from your test run with your normal lcov/gcov workflow.

3. Find the gaps

Coverage + change = a focused test plan

Coverage of the code a change touched is the most useful slice. Combine these metrics with test prioritization from code changes to see whether the affected code is actually tested.

Where to next