Hello, you are using an old browser that's unsafe and no longer supported. Please consider updating your browser to a newer version, or downloading a modern browser.

Global Accelerated Learning • Est. 1999
Glossary Term Condition Coverage

Training Camp • Cybersecurity Glossary

What is Condition Coverage?

A code-coverage metric ensuring every boolean sub-condition in a decision evaluates both true and false at least once during testing.

Glossary > Application & API Security > Condition Coverage

Condition Coverage — A code-coverage metric ensuring every boolean sub-condition in a decision evaluates both true and

Understanding Condition Coverage

Condition coverage is a white-box software testing metric that measures whether each individual boolean sub-condition within a decision has been evaluated as both true and false at least once. It is finer-grained than decision (branch) coverage, which only requires the overall decision outcome to be tested both ways, because a compound decision can take both branches without every sub-condition being independently exercised.

It works by decomposing each decision into its atomic boolean expressions. For a condition like (A AND B), condition coverage requires test cases where A is true and false and where B is true and false, ensuring each operand is individually toggled. Note that condition coverage alone does not guarantee decision coverage, and the stronger Modified Condition/Decision Coverage (MC/DC) additionally requires showing that each condition independently affects the outcome. Coverage tools instrument the code and report which conditions reached both values; standards such as ISO/IEC 29119 and safety-critical guidance like DO-178C reference these criteria.

This matters for security because untested logic is where vulnerabilities hide, particularly in authentication, authorization, and input-validation checks built from compound conditions. If a sub-condition is never evaluated false, a flawed check, such as one that grants access when it should deny, can pass all tests yet fail in production. Demanding high condition coverage on security-critical decision logic forces tests to exercise the very branches attackers probe.

For example, an access-control function reads if (user.isAuthenticated AND user.hasRole('admin')). A test suite that only ever runs with an authenticated admin achieves decision coverage for the true branch but not condition coverage, because hasRole is never tested as false and isAuthenticated may never be false either. Requiring condition coverage forces cases for an authenticated non-admin and an unauthenticated user, revealing whether the function correctly denies access in each scenario. Many security-critical projects mandate 100 percent condition coverage, or MC/DC, on authorization logic for exactly this reason.

Learn More About Condition Coverage:

Ready to Get Certified?

Turn knowledge into credentials with our instructor-led cybersecurity boot camps.

View All Courses →