Great work!

XP to next level

BugEater

Exclusive Conditions & Mutual Constraints

Learning Objectives

By the end of this lesson you will be able to:

  • Apply the four constraint types (E, I, O, R) to cause-effect graphs
  • Generate test cases specifically targeting mutual constraints
  • Explain why constraint violations are among the most common real-world bugs

The Gap in Basic C-E Graphs

Basic cause-effect graphs model what should happen when causes combine. But they don't model what is forbidden. In the real world, some combinations of causes are impossible by design — you cannot select both "pay by credit card" and "pay by cash" at the same time. Others are required — at least one payment method must be selected.

These restrictions are constraints, and they add a critical layer of realism to your graph.

The Four Constraint Types

E (Exclusive)

At most one of the marked causes can be true at the same time. "You cannot select both premium and basic plans simultaneously."

Test implication: Try selecting both — the system must reject or automatically deselect one.

I (Inclusive)

At least one of the marked causes must be true. "At least one notification method (email or SMS) must be selected."

Test implication: Try selecting neither — the system must reject or warn.

O (One-and-only-one)

Exactly one of the marked causes must be true — not zero, not two. "Exactly one shipping method must be chosen."

Test implication: Test zero selections (I violation) AND two simultaneous selections (E violation).

R (Requires)

If cause A is true, cause B must also be true. "If express shipping is selected, an address must be entered."

Test implication: Try selecting A without B — the system must block or warn.

A Real Example: Tariff Constructor

A telecom form has three optional services: Call Forwarding (A), Voicemail (B), and Call Recording (C). The business rule: "Call Forwarding and Voicemail cannot both be active — they use the same call routing slot."

This is an E constraint between A and B.

Test cases the constraint generates:

  1. A=on, B=off, C=any → valid
  2. A=off, B=on, C=any → valid
  3. A=on, B=on, C=any → must fail — constraint violated

The backend must detect and reject combination 3. Does it? That's your test.

Pro Tip: Constraint violations are where the nastiest bugs hide. The happy-path test suite never touches them. The developer usually handles the positive case (A and B work independently) and forgets to validate that they can't coexist.

Constraints on Effects

Constraints can also apply to effects (outputs). "The system cannot simultaneously display both an 'approved' and a 'pending' message." These are rare but worth checking in UIs where multiple async processes can complete in unexpected orders.

Summary

Constraint annotations transform a basic C-E graph into a complete model of what's possible, required, and forbidden. The E (exclusive), I (inclusive), O (one-and-only-one), and R (requires) constraints generate the test cases for the most exploitable gaps in real implementations. In the next lesson, you'll convert a complete graph into a test suite.

Quiz

An "exclusive" constraint between conditions C1 and C2 means:

A system has a constraint: "requires C1 whenever C2 is true." What kind of constraint is this?

When testing a pair of exclusive conditions, which test case is MOST important to include?

What risk does a MASK constraint introduce in testing?