MC/DC coverage guide:
examples, test cases
and tools

01 / The idea

What is MC/DC coverage?

A test can execute a line without challenging the logic on it. It can take both exits from a decision without showing why either exit was taken. MC/DC adds a more demanding question: can this condition change the decision when the influence of the other conditions is controlled?

The unit of evidence is an independence pair: two executions or model assignments that satisfy the selected MC/DC rule for a particular condition. Different conditions can reuse the same test. The full structural criterion also includes condition outcomes, decision outcomes, and entry/exit execution. A report limited to Boolean pairs must say that is its scope.[1]

Our teaching rule sounds an alarm when temperature is high and cooling has failed, or a manual alarm is active. Here, A means “temperature high,” B means “cooling failed,” and C means “manual alarm.” Treat the three inputs as independent Boolean values. Real sensor thresholds, timing, fault states and actuator behavior need their own requirements and checks.

#include <stdbool.h>

bool alarm(bool hot, bool cooling_failed, bool manual_alarm) {
    return (hot && cooling_failed) || manual_alarm;
}

02 / Original experiment

100% branch coverage.
A condition still has no witness.

We compiled the equivalent C predicate with GCC 13.3.0 at -O0 --coverage and ran three cases. Then we inspected gcov -b -c. The result: all six compiler-reported branch outcomes were taken. Each of the three conditions also evaluated both true and false in these executions. Yet no pair establishes B’s independent effect.

Look only at the two cases in which B is evaluated: 101 and 110. B changes, but the decision stays true. The supplied C input also changes; C is skipped in 110. There is no evidence here that B can change the final answer.

MC/DC test cases: a four-case worked example

Add 100 → false. Now 100 ↔ 110 isolates B, and 100 ↔ 101 isolates C. The original 010 ↔ 110 pair already isolates A in the complete-input model. Four cases establish all three logical independence obligations:

These columns show supplied inputs, including values that short-circuit execution may skip. The interactive trace table shows which conditions actually get evaluated in the model.

The consequence is concrete: the wrong rule A || C, with the cooling condition accidentally removed, returns the same answers for all three original inputs. The added case 100 distinguishes them: the intended rule returns false; the broken rule returns true. That is one specific fault this extra case exposes, not a guarantee against every defect.

Raw branch report ↗Inputs, outputs & calculation ↗Reproduce the experiment ↓

How we checked the original result

There are eight complete input assignments for three independent Booleans, and 256 possible subsets of those assignments. We evaluated every subset against the strict rule: only the target input changes and the decision changes. 26 subsets qualify; the smallest have four cases; exactly two four-case suites qualify. They are {010, 011, 100, 110} and {010, 100, 101, 110}.

The calculation assumes all eight assignments are feasible. Python enumeration was checked against compiled C outputs for all eight rows, and the browser’s implementation was compared with all 256 expected subset results. These are reproducible findings about this example, not a claim about the number of tests every project needs. The kit contains the source, scripts, commands and recorded outputs.

03 / Count the obligations

How to calculate MC/DC coverage

First define what the report counts. For this guide’s logical condition-independence score, divide the number of conditions with at least one valid pair by the number of condition obligations, then multiply by 100:

Count each condition obligation once, even if it has several valid pairs. Across decisions using the same counting unit, add the satisfied obligations and total obligations before dividing. For a hypothetical report with three obligations in one decision and five in another, (1 + 3) ÷ (3 + 5) = 50%; averaging 1/3 and 3/5 would incorrectly give about 46.7%.

The browser lab below implements this exact fixed model. It calculates test-pair adequacy; it does not instrument your application.

05 / The working method

How to design MC/DC test cases and measure coverage

Start from behavior you can explain. Use coverage to challenge the resulting test suite, and investigate what the measurement leaves unresolved. Writing tests solely to turn a report green can preserve the implementation’s mistakes.

1 Write the requirement and the expected result

Describe when the decision should be true, when it should be false, and which failures matter. State the units, boundaries and relevant state. For the alarm example, “temperature high” still needs a threshold rule; “manual alarm” needs an agreed meaning. Derive expected outcomes from that agreement, rather than copying what today’s function happens to return.

2 Inventory the actual decisions and condition occurrences

Identify the scoped functions, build configuration and expressions the tool can measure. Count each condition occurrence, including repeated occurrences, and confirm how the instrumenter maps them. (A && B) || (A && C) contains two occurrences of A; a calculator that silently merges them changes the coverage problem. Keep unsupported constructs visible.

3 Choose the variant and find feasible witness pairs

Write down whether you need strict unique-cause, a short-circuit-aware interpretation, or masking MC/DC. For each condition, find two feasible cases that satisfy that rule. Record why the other conditions cannot explain the decision change. If a proposed combination is impossible, preserve the constraint and investigate it; inventing an impossible test does not close a gap.

For strict pairs, choose a context in which the target can determine the result, then flip only that input. Here is how to construct the pairs for (A && B) || C:

Other contexts can expose C too. Whatever context you choose, verify that both assignments can reach the decision in the real application.

Download the test-pair worksheet to adapt the example. Record each requirement, condition, input pair, expected result, fixed context and feasibility constraint. After execution, add the code revision, test IDs, tool version and measured-witness reference; keep the status “planned” until that run exists. Import three-bit input assignments as text in a spreadsheet to preserve leading zeros.

4 Implement assertions and run the instrumented build

Translate each case into real inputs and assert the required output or state change. Preserve the language’s evaluation order and side effects. Run the compiler or source instrumenter that supports the chosen coverage criterion. A test plan, an imported line report and a successful test command are three different artifacts.

5 Inspect the missing obligations, not just the percentage

Read the per-decision conditions, outcomes, witness pairs and skips. Investigate unreachable combinations, unsupported expressions, deactivated configurations and unexpected executable code. A denominator reduced by exclusions needs a reviewable explanation. Make partial execution and missing instrumentation explicit rather than letting them look like a pass.

6 Keep the evidence tied to the change

Retain the requirement version, source revision, tool and version, build flags, test identifiers, inputs, assertions, results and exclusions. Name the reviewer or acceptance authority. When code, configuration or intent changes, determine which evidence needs rerunning. A passing report from another revision is historical evidence.

This workflow joins requirements-based verification with structural coverage analysis. The distinction is central to the DO-178C assurance discussion: coverage helps assess how thoroughly requirements-based tests exercised the structure.[3]

06 / What costs you later

MC/DC mistakes and their consequences

The expensive part is often discovering that the evidence cannot support the decision you already made. Catch these gaps while the requirement, code and tests are still easy to change.

One useful review question is: What could still be wrong even if every obligation in this report passes? The answer helps decide which boundary, property, integration, fault-injection or concurrency checks to add.

07 / Know the denominator

MC/DC vs branch, condition and multiple-condition coverage

Coverage numbers describe different obligations. A “100%” label is meaningful only with its metric, supported scope and treatment of exclusions. Compiler branch edges also need not map one-to-one to the source-level decisions a reader sees.

The three-test experiment above is a concrete counterexample to “branch plus condition coverage implies MC/DC.” Both ordinary metrics are satisfied, but B has no independent-effect witness. The four-case logical suite is also not exhaustive: the model has eight assignments and five distinct short-circuit traces, and that suite omits the trace F – T.

Unique-cause vs masking MC/DC

The target condition and decision must change. These selected interpretations differ in which other changes they permit and how they treat conditions that were not evaluated.

In the starter suite, GNATcoverage’s documented masking interpretation can credit C using 010 ↔ 101: A && B is false in both cases. Strict complete-input unique-cause rejects that pair because A and B change too. B still has no witness in either analysis. This is why the lab labels its result “strict logical independence” instead of pretending all tools will report the same percentage.[11]

Does MC/DC always need n + 1 tests?

No. For strict unique-cause analysis with n independently demonstrable condition occurrences, n + 1 is a lower bound; some expressions attain it. Our three-condition example does, with four cases. It is not a universal exact count across expressions, input domains or MC/DC variants. Coupling can also make a particular obligation infeasible. Calculate the pairs and their feasibility rather than treating the count as a coverage certificate.[2]

For this model, “four cases instead of all eight assignments” is an exact result. It is not a promise to halve a project’s test suite. Each Boolean case can still need several real values, boundary checks, error paths and integration contexts.

When is MC/DC required?

The answer depends on the applicable assurance framework, software criticality, and agreed verification approach. Establish those first. A coverage percentage cannot decide which obligations apply to your product.

Airborne software: DO-178C / ED-12C

DO-178C increases structural coverage rigor with software level. NASA’s analysis of the standard summarizes the progression below. These are structural coverage objectives within a larger requirements-based verification process; achieving them does not complete certification.^NASA

FAA AC 20-115D recognizes DO-178C as an acceptable means of compliance. The advisory circular explicitly says it is not a regulation or the only possible means. Applicable provisions must be followed when its approach is used.^FAA

Also establish the analysis basis: source code, object code or executable object code. The FAA’s DO-178B/C comparison highlights additional verification for compiler-generated executable code that is not directly traceable to source statements, and coverage of data and control coupling between components. A source-level MC/DC percentage does not by itself resolve these obligations. The same comparison records an independence form that allows masking; this guide’s stricter logical model is a teaching choice.[16]

NASA safety-critical software

NPR 7150.2D §3.7.4, SWE-219, requires 100% MC/DC code-test coverage for identified safety-critical software components. Deviations require review and waiver with rationale and technical-authority approval. This scope does not extend automatically to every component in every space project.^NPR

Automotive software: establish the applicable ASIL

ISO 26262-6:2018 covers software development and verification for automotive functional safety. For MC/DC decisions, consult the licensed edition’s software-unit verification and structural-coverage provisions, and your project’s ASIL and safety plan. Confirm the method recommendations and any required justification against that edition. The public catalogue establishes its edition and scope, rather than the full method requirements.^ISO

Qualification depends on how the tool is used

For certification work, assess whether relying on the coverage tool requires qualification. AC 20-115D points to DO-178C §12.2 and DO-330 for this assessment. A supported tool or qualification kit still needs to fit the intended use, version, configuration, and project context.^{FAA §10}

09 / Proof and coverage tools

MC/DC tools for your codebase

Start with the toolchain and target you must support. Then check the reported criterion, instrumentation limits, and evidence requirements. The best fit is the option whose results you can reproduce and explain within that environment.

Tool names alone do not establish equivalent measurements. For example, GNATcoverage distinguishes masking MC/DC, selected with stmt+mcdc, from unique-cause plus short-circuit handling, selected with stmt+uc_mcdc. Record the selected interpretation beside the result. ^Variants

How we compared the options

This guide is published by Proof and includes our own offering. It is a practical selection guide, not a scored benchmark. We checked official documentation for supported workflows, version requirements, coverage semantics, and instrumentation limits. Proof’s language scope also uses a 27 October 2026 implementation review, with the measurement limits stated above.[20] We did not run a comparative performance study, obtain commercial quotations, or evaluate a qualification package.

Before choosing, take one representative decision through the complete process: compile, execute, inspect its independence evidence, explain exclusions, and reproduce the report from a clean build. Check that someone reviewing the result can identify the code revision, tests, compiler settings, and criterion used. Treat qualification effort and ongoing maintenance as part of the decision.

For an embedded target, also confirm how execution data will leave the device, what storage the instrumented build needs, and whether instrumentation affects the behavior being assessed. Ask the supplier to demonstrate the workflow on your language constructs and build configuration. A successful desktop example establishes a useful starting point; target suitability still needs evidence.

A test-pair planner serves a different purpose: it proposes inputs under a logical model. Your coverage tool observes what the compiled program actually evaluates. Keep both artifacts when they are useful, and investigate differences in reachability, short-circuit handling, or the reported criterion.

Run it against real code

Proof: start with the measured Go example

With the Proof CLI already installed, download the example from the Go measurement guide and run this from its mcdc-cache directory:

proof mcdc measure ./cache --engine go --format json

The command instruments supported decisions and runs project tests. Inspect the resulting conditions, witness pairs and run provenance alongside the requirement assertions. The linked guide includes the recorded run; this command was not rerun for the present article.[13]

Independent C/C++ compiler workflows

Download the MC/DC evidence kit and open instrumentation-demo/. Its four-case fixture exercises (A && B) || C and checks the expected outcomes. The kit separately preserves the original three-case and four-case GCC 13.3 branch experiments under branch-experiment/.

Validation boundary: we executed the ordinary C fixtures and the GCC 13.3 branch experiment. The MC/DC recipes below were checked against release documentation but were not executed for this guide. Their output is something to measure in your environment; no compiler MC/DC result is claimed here.

Clang / LLVM 18.1.8

Use matching 18.1.8 versions of clang, llvm-profdata, and llvm-cov. Instrument the decision and compile the test runner separately. This keeps the teaching report focused on the decision. ^Clang

clang -std=c11 -O0 -fprofile-instr-generate -fcoverage-mapping \
  -fcoverage-mcdc -c decision.c -o decision.o
clang -std=c11 -O0 -c runner.c -o runner.o
clang -fprofile-instr-generate decision.o runner.o -o mcdc-demo
LLVM_PROFILE_FILE=mcdc.profraw ./mcdc-demo
llvm-profdata merge -sparse mcdc.profraw -o mcdc.profdata
llvm-cov show ./mcdc-demo -instr-profile=mcdc.profdata \
  -show-mcdc -show-branches=count decision.c
llvm-cov report ./mcdc-demo -instr-profile=mcdc.profdata \
  -show-mcdc-summary decision.c

The MC/DC detail view and summary must be requested explicitly. LLVM 18.1.8 limits instrumentation to six leaf conditions per expression and warns about unsupported expressions. These are release-specific limits; inspect the documentation and warnings for any other version you use.^{llvm-cov Limits}

GCC 14 or later, with matching gcov

Use a fresh copy of instrumentation-demo/ for this run. The additional condition flag collects the evidence needed by --conditions; a branch-only report does not answer the same question.^{GCC flagsgcov}

gcc -std=c11 -O0 --coverage -fcondition-coverage \
  -c decision.c -o decision.o
gcc -std=c11 -O0 -c runner.c -o runner.o
gcc --coverage decision.o runner.o -o mcdc-demo
./mcdc-demo
gcov --conditions decision.c

The GCC implementation author documents a 32- or 64-condition bitset limit in GCC 14, depending on the target and configuration. Check the diagnostics and release documentation for your exact build; do not transfer a version-specific limit to every later release.[19]

Keep the source revision, build commands, tool versions, test inputs, expected and observed results, report, and any exclusions together. Start independent campaigns with fresh profiles. A reproducible result gives the next reviewer something concrete to inspect.

For your own code, connect each added test to the intended behavior and a meaningful expected result. Confirm that the proposed inputs can reach the decision in the real program. Four convenient Boolean assignments do not establish a complete test plan for the surrounding feature.

10 / Put it to work

Choose your next step

For QA and test engineers

Use the pairs as a review surface. Ask what each test is trying to isolate and whether its expected result comes from the requirement. Keep concrete inputs and assertions beside the case ID. A reusable witness table is more useful than a collection of unnamed fixtures.

For developers working with coding agents

Give the agent a behavior to preserve, an input domain and explicit evidence obligations. Let it propose cases and run supported checks. Keep the authority to approve intent and accept the change clear. A generated test that agrees with generated code still needs an independently justified expectation.

For safety-critical and regulated teams

Start from the applicable standard, software level, target configuration and approved verification plan. Resolve variant, instrumentation, tool qualification and exclusion handling before relying on a report. Use this guide to understand the evidence; use the governing documents to determine your obligations.

For product managers and requirement owners

Use the truth table to expose decisions hidden inside prose: what happens at the boundary, when an override is present, or when inputs disagree? You do not need to choose compiler flags to review whether the modeled behavior matches the product promise.

When MC/DC is not enough

MC/DC is not a complete strategy for a distributed workflow, a timing guarantee, a concurrency argument, a security assessment or a certification decision. It also cannot discover a requirement simply because the code omitted it. Use it where decision logic matters, alongside checks for the other risks. Do not pursue a universal percentage before deciding which claim that percentage should support.

Who this guide is not for

If your immediate need is an end-to-end test plan for an entire product, start with its requirements, hazards and interfaces; this guide covers one part of that plan. If you need certification credit, work from the governing standard and your approved verification process. If the feature’s main risk is timing or concurrency, prioritize evidence that exercises those behaviors as well as any decision logic.

More examples / Numbers you can check

Two more examples that sharpen the distinction

1. A coupled predicate can make an obligation impossible

Let A be x > 0 and B be x > 10 in A && B. To make A independently affect the decision, B must be true while A changes. But x > 10 implies x > 0. The required A=false/B=true input cannot occur. Review the redundant predicate and requirement; an invented input cannot fix the problem.

2. An omitted requirement survives complete predicate coverage

Suppose the alarm must also sound when a sensor reports a fault. The predicate (A && B) || C never reads that fault. With A=B=C=false and a fault present, it returns false even though the added requirement expects true. Every existing condition can have a witness and the behavior can still violate the promise. The missing rule needs a requirement, implementation and regression check of its own.

That is the point of keeping intent and observed coverage together. If one decision in your code has become difficult to explain, bring that decision and the behavior it must preserve to Proof.

Continue with the evidence