covmetric -p coverage.cov | grep "Decision Coverage" | awk 'if ($3 < 80) exit 1' The landscape has shifted. Here's when to choose Bullseye vs. newer tools:
// The tool tracks both true and false evaluations.
The instrumented source is then compiled and linked with Bullseye’s runtime library. You run your test suite normally (unit tests, integration tests, fuzzing). As the binary executes, the probes increment counters in shared memory or a .cov data file. Bullseye is remarkably low-overhead—typically 10-30% slowdown, making it viable for large test suites. Phase 3: Merging & Reporting ( covselect , covbr , covhtml ) This is where Bullseye shines. You can run tests across 1000 different processes, on different machines, at different times, and then merge all the .cov files into a single aggregate report. The command covmerge intelligently sums counters without double-counting. 3. Deep Dive: Decision Coverage (The "True" Bullseye Metric) Many teams erroneously believe 100% line coverage equals "tested." Consider this C++ function: bullseye code coverage
// Original code if (temperature > 100 && pressure < 50) activate_alarm();
set(CMAKE_C_COMPILER "covc" CACHE STRING "") set(CMAKE_CXX_COMPILER "covc" CACHE STRING "") set(CMAKE_CXX_COMPILER_LAUNCHER "" CACHE STRING "") set(CMAKE_C_COMPILER_ARG1 "--compiler" CACHE STRING "") set(CMAKE_CXX_COMPILER_ARG1 "--compiler" CACHE STRING "") export PATH=/usr/local/bullseye/bin:$PATH covselect --add --on # Turn on coverage measurement cmake -DCMAKE_TOOLCHAIN_FILE=bullseye-toolchain.cmake .. covbuild cmake --build . --parallel Step 3: Run Tests & Capture Data cov01 -1 # Reset counters to zero ./bin/my_unit_tests covrun ./bin/integration_tests Step 4: Merge & Report covmerge -a *.cov # Merge all .cov files into one covhtml --title "Sprint 23 Coverage" -o coverage_html coverage.cov Step 5: Set a Quality Gate In your CI script, fail the build if decision coverage drops below 80%: covmetric -p coverage
Introduction: The Evolution of Code Coverage Tools In the landscape of software quality assurance, code coverage metrics serve as the bedrock for understanding how thoroughly your tests exercise your application. While open-source tools like gcov (GCC) and lcov are widely known, the commercial sector has long relied on a powerful, precision-focused solution: Bullseye Coverage .
cov01 -1 # Instrument source make # Build covrun ./run_tests # Execute covhtml -o coverage_report *.cov # Generate HTML Automotive (ISO 26262 ASIL-D) In autonomous driving software, a single untested branch in a lane-keeping algorithm could cause a fatality. Bullseye is used to achieve Modified Condition/Decision Coverage (MC/DC) , which is required for ASIL-D. Bullseye’s reports can be directly submitted to certification auditors. Medical Devices (FDA Class III) The FDA requires objective evidence of test completeness. Bullseye’s ability to exclude TESTMARGIN regions (e.g., "this error handler is only for cosmic ray bit flips") and merge coverage from 10,000 hours of simulation is unmatched. Legacy Code Refactoring When taking over a million-line C++ codebase with 0% tests, Bullseye helps prioritize. Run a smoke test, generate a report, and refactor the red (uncovered) and yellow (partial) functions first. This risk-based testing approach saves months of effort. 6. Limitations and Critical Considerations No tool is perfect. Bullseye has notable constraints: The instrumented source is then compiled and linked
// After Bullseye instrumentation (conceptual) probe_1 = 0; // Counter for the decision if (temperature > 100 && pressure < 50) probe_1++; // Counts entry of the true branch activate_alarm();