Move beyond simply running tests and learn how to assess what those tests actually exercise.

This four-hour module develops practical understanding of structural code coverage and Modified Condition/Decision Coverage (MC/DC). Participants measure statement and branch coverage across C/C++, Python and Rust, identify coverage gaps and write targeted tests to close them.

The module then moves into MC/DC theory and manual derivation, including independence pairs, masking and unique-cause MC/DC, short-circuit evaluation and truth-table-based test-set design.

Participants bring the work together in a Coverage & MC/DC Verification Report that combines measured structural coverage with a documented MC/DC test set.

View the Full Software Testing & Verification Programme

What You Will Learn

Module 4 develops the ability to assess test effectiveness using structural coverage evidence rather than relying only on whether a test suite passes or fails.

Participants learn how statement, branch, condition and path coverage relate to each other, how to interpret coverage reports, and how to identify untested implementation paths.

The module then introduces MC/DC in more depth, including:

• Independence pairs
• Masking MC/DC
• Unique-cause MC/DC
• Short-circuit evaluation
• Systematic truth-table derivation
• The relationship between MC/DC and DO-178C Level A

The practical work connects coverage measurement with test improvement and then extends that reasoning into manual MC/DC test-set construction.

Topics

• The coverage hierarchy: statement, branch, condition and path coverage
• Coverage tooling: gcov/lcov, coverage.py, cargo-tarpaulin
• Reading coverage reports and identifying coverage gaps
• Coverage targets by criticality tier; diminishing returns beyond a threshold
• Modified Condition/Decision Coverage (MC/DC): formal definition and independence pairs
• Masking MC/DC vs unique-cause MC/DC
• Short-circuit evaluation and its effect on achievable independence pairs
• Deriving MC/DC test sets manually using a truth-table method
• MC/DC and its mandated role at DO-178C Level A

Lab 1: Cross-Language Coverage Measurement

Learning Objectives: gcov/lcov, coverage.py, cargo-tarpaulin, coverage gap analysis

Description: Measure statement and branch coverage for the same logical function implemented in C/C++, Python and Rust.

Tasks

• Instrument and run a C/C++ sample with gcov, then generate an lcov HTML report.
• Run coverage.py in branch-coverage mode against the Python equivalent.
• Run cargo-tarpaulin against the Rust equivalent.
• Identify one untested branch in each report.
• Write one targeted test per language to close the identified gap.
• Compare the three tools’ report formats side by side.

Extension Tasks

• Mark one line as intentionally excluded using each language’s exclusion syntax (e.g. pragma: no cover).
• Set a per-language coverage target by criticality tier.

Topics Covered

gcov/lcov, coverage.py, cargo-tarpaulin, Coverage Gaps

Open Source Recommendation

gcov/lcov, coverage.py and cargo-tarpaulin: open-source coverage tools native to their respective toolchains.

Lab 2: Deriving MC/DC Test Sets Manually

Learning Objectives: MC/DC, independence pairs, masking vs unique-cause MC/DC

Description: Derive an MC/DC-compliant test set for a multi-condition decision using a systematic truth-table method.

Tasks

• Build a truth table for a three-condition decision (A && B || C).
• Identify an independence pair for each condition.
• Derive a minimal unique-cause MC/DC test set for the decision.
• Derive the equivalent masking MC/DC test set and compare the two.
• Identify the impact of short-circuit evaluation on achievable pairs.
• Trace each MC/DC test case back to the statement and branch coverage already achieved.

Extension Tasks

• Extend the method to a four-condition decision.
• Identify a coupled-condition case where independence cannot be fully achieved.

Topics Covered

MC/DC, Independence Pairs, Masking vs Unique-Cause MC/DC

Open Source Recommendation

No dedicated tool is required for manual derivation; the truth-table method is tool-independent and transfers directly to any language.

Module 4 Coverage Matrix

Module Project: Coverage & MC/DC Verification Report

Coverage & MC/DC verification report: measure statement/branch coverage for a decision-heavy sample function across all three languages, then manually derive and document its MC/DC test set.

The project combines both halves of the module into a single verification deliverable.

Participants first generate measurable coverage evidence across C/C++, Python and Rust, then connect that evidence to a manually derived MC/DC test set for a decision-heavy function.

The result demonstrates a progression from:

Test execution → coverage measurement → gap identification → targeted testing → MC/DC reasoning

From Passing Tests to Coverage Evidence

A passing test suite shows that the executed tests produced the expected outcomes. Structural coverage provides a different form of evidence: it shows which parts of the implementation have actually been exercised.

Module 4 therefore builds directly on the executable test suites developed in Module 3 – Unit & Component Testing.

The programme progression becomes:

Unit & Component Tests
↓
Structural Coverage Measurement
↓
Coverage Gap Analysis
↓
MC/DC Test Derivation

This keeps Module 4 focused on evidence of test completeness at the code-structure level rather than general unit testing.

Structural Coverage Across C/C++, Python and Rust

The first lab deliberately applies comparable coverage thinking across three language ecosystems.

Participants use:

C/C++
gcov and lcov

Python
coverage.py

Rust
cargo-tarpaulin

The aim is not simply to generate reports. Participants identify untested branches, add targeted tests and compare how the tools present structural coverage information.

This cross-language approach also prepares the resulting coverage data for later automation in Module 11 – Test Automation & CI/CD Integration.

Understanding MC/DC

MC/DC goes beyond simple statement or branch coverage by examining whether individual conditions can independently affect a decision outcome.

In this module, participants work through that reasoning manually rather than relying on a tool to hide the process.

The exercises cover:

• Condition independence
• Independence pairs
• Unique-cause MC/DC
• Masking MC/DC
• Short-circuit behaviour
• Truth-table-based test derivation
• Coupled-condition cases

This makes the MC/DC section a technical reasoning exercise as well as a testing activity.

How Module 4 Connects With Later Modules

The structural coverage and MC/DC evidence developed here becomes especially relevant later in the programme.

Module 5: Requirements-Based Testing & Traceability

Coverage evidence can be considered alongside requirements-derived tests and traceability evidence.

Module 11: Test Automation & CI/CD Integration

Module 11 automates gcov/lcov, coverage.py and cargo-tarpaulin and introduces coverage-based pipeline gates.

Module 12: Cross-Industry Standards Bridge & Capstone

This is a particularly important contextual internal link because it gives Module 4 a clear place within the complete verification evidence chain.

Frequently Asked Questions

What is covered in the Structural Code Coverage & MC/DC module?

The module covers statement, branch, condition and path coverage, coverage-gap analysis, MC/DC, independence pairs, masking and unique-cause MC/DC, short-circuit evaluation and manual truth-table-based MC/DC derivation.

Which code coverage tools are used?

Participants use gcov/lcov for C/C++, coverage.py for Python and cargo-tarpaulin for Rust.

Does the module cover MC/DC practically?

Yes. Participants manually derive an MC/DC-compliant test set for a multi-condition decision using a systematic truth-table method.

What is the difference between masking and unique-cause MC/DC?

Both approaches are addressed in the module. Participants derive and compare masking and unique-cause MC/DC test sets as part of Lab 2.

Does the module cover short-circuit evaluation?

Yes. Participants examine how short-circuit evaluation affects achievable MC/DC independence pairs.

Does this module cover DO-178C?

The curriculum introduces MC/DC and its mandated role at DO-178C Level A. Broader cross-standard mapping is developed later in Module 12.

Is MC/DC calculated using a commercial tool?

The MC/DC derivation exercise does not require a dedicated tool. The curriculum uses a tool-independent truth-table method.

What is the Module 4 project?

The project is a Coverage & MC/DC Verification Report combining statement/branch coverage across C/C++, Python and Rust with a manually derived and documented MC/DC test set.