Compare the evidence your project needs

Understand the product scope

LDRA’s tool suite combines requirements traceability, static and dynamic analysis, structural coverage and testing. Its published language list includes C, C++, Java and Ada95, and is explicitly partial. Confirm support for your exact language, compiler, target and product configuration with LDRA. LDRA tool suite overview.

LDRA also documents CI integration, including verification activities orchestrated through GitHub Actions and Jenkins. Running in CI is therefore not a useful dividing line between the products. LDRA continuous integration capabilities.

Proof connects requirements, code, verification evidence, known issues and changes in the repository’s assurance record. A useful evaluation asks whether that record helps your reviewers recover the intended behavior, identify affected obligations and see which evidence is missing or stale when a change arrives. Code-level MC/DC is one instrument within that workflow.

Coverage answers one part of the question

Consider an illustrative Go decision that serves a cached response only when a user is authorized and the entry is fresh:

return authorized && fresh

Executing the true branch once shows that the return path ran. Showing each condition’s independent effect requires contrasting observations: true/true with false/true for authorization, and true/true with true/false for freshness. Those observations must come from real executions before they count as measurement evidence.

Even complete coverage of this decision does not establish that the authorization check is correct or that “fresh” matches the product’s promise. The requirement, test oracle and actual output still need review.

A concrete Proof trial on Go

proof mcdc measure ./... --engine go
proof audit --check code_mcdc_coverage

The first command instruments a copied workspace and runs tests. The audit check evaluates available measurement evidence for configured targets; running that check in isolation does not execute a fallback test runner. With no enabled targets it skips. Thresholds, advisory settings and CI enforcement determine what the result prevents.

Inspect the measured scope, uncovered decisions, exclusions and evidence freshness alongside the test result. For C/C++, the project’s build and test command must produce the LLVM or gcov coverage export that Proof imports.

Keep the qualification decision explicit

LDRA describes its TQSPs as optional support for qualifying the tool in a project-specific environment. That is more precise than treating an entire toolchain as universally qualified. Establish which tool functions and outputs your verification plan relies on and what evidence your project requires. LDRA qualification support.

If your project already relies on a qualified verification workflow, retain it while evaluating any additional tool. A Proof trial can examine a bounded change and its supporting evidence without implying that a coverage report establishes certification readiness.