Write it the way it appears in the code. Both symbol and word forms parse, so A && B and A and B are the same thing.
| Test | A | B | C | (A || B) && C | |
|---|---|---|---|---|---|
| 1 | T | F | T | T | row 3 of the table |
| 2 | T | F | F | F | row 4 of the table |
| 3 | F | T | T | T | row 5 of the table |
| 4 | F | F | T | F | row 7 of the table |
| Condition | Pairs available | The pair used | What it proves |
|---|---|---|---|
| A | 1 | TFT vs FFT | Hold the others, flip A, and the outcome flips T to F |
| B | 1 | FTT vs FFT | Hold the others, flip B, and the outcome flips T to F |
| C | 3 | TFT vs TFF | Hold the others, flip C, and the outcome flips T to F |
| Row | A | B | C | (A || B) && C | |
|---|---|---|---|---|---|
| 1 | T | T | T | T | |
| 2 | T | T | F | F | |
| 3 | T | F | T | T | in the set |
| 4 | T | F | F | F | in the set |
| 5 | F | T | T | T | in the set |
| 6 | F | T | F | F | |
| 7 | F | F | T | F | in the set |
| 8 | F | F | F | F |
Tests required, by criterion
The shape of the argument for MC/DC is in the last two columns. Branch coverage stays at two tests however many conditions there are, full multiple condition coverage doubles with each one, and MC/DC grows by one.
| Decision | Conditions | Branch coverage | MC/DC | Every combination |
|---|---|---|---|---|
| A && B | 2 | 2 | 3 | 4 |
| A || B | 2 | 2 | 3 | 4 |
| (A || B) && C | 3 | 2 | 4 | 8 |
| A && B && C | 3 | 2 | 4 | 8 |
| A && (B || C) && D | 4 | 2 | 5 | 16 |
| A && B || C && D | 4 | 2 | 5 | 16 |
Branch coverage needs two tests for every decision on this list, including the four condition ones. That is not a summary of the criterion, it is the criterion: come out true once, come out false once. MC/DC is n plus 1 throughout.
A worked example
Take D = A and B, the example DO-178C tutorials use. Branch coverage is satisfied by two tests: A true with B true giving true, and A false with B false giving false. Both outcomes of D are exercised, so the tool reports one hundred percent.
But A and B changed together between those two tests, so neither was shown to independently drive the result. A bug that ignores B entirely, implementing D = A, passes both of them. Branch coverage is blind to it, and no amount of running that suite again will reveal it.
MC/DC needs three tests, and it prints why. For A: hold B true, flip A from true to false, and the outcome flips. For B: hold A true, flip B from true to false, and the outcome flips. Each condition is now shown to matter on its own, and the D = A bug dies on the second test, where A is true, B is false, and correct behaviour is false.
Now try (A or B) and C in the tool. MC/DC goes to four tests, branch coverage stays at two, and fifteen different pairs of tests all satisfy branch coverage while reporting the same one hundred percent. The criterion gives you no way to ask for a good pair.
The finding worth the most is one the tool reports as a failure. Enter A and not A and it will tell you that A has no independence pair. That is not a testing problem. The condition is in the source and cannot change the result, whatever anything else does, and the fix is to the decision.
The arithmetic, so you can check it
An independence pair for condition c is two rows of the truth table differing in exactly c, whose outcomes differ. That is unique-cause MC/DC, which is the definition DO-178C's worked examples use. The test set is a set of rows covering one such pair for every condition.
Since every condition needs a pair and pairs can share rows, n + 1 is the floor. When the tool reaches it, the answer is provably minimum and it says so. When it cannot, it reports the smallest set it found and says that instead, because exact minimisation here is set cover and therefore NP-hard.
This computes unique-cause MC/DC. Masking MC/DC is a legitimate weaker variant that some tools and some certification arguments accept, and it will sometimes admit a smaller set; it is deliberately not implemented, because the point of the tool is to show independence rather than to find the cheapest defensible number. Note also that MC/DC is a criterion on one decision, not a guarantee about a program. Inozemtseva and Holmes explicitly observe that a requirement like DO-178B MC/DC may increase expenses without necessarily increasing quality, and that finding stands alongside this tool rather than being answered by it.
The standard and the worked example are in what DO-178C and MC/DC actually require. To see how many injected faults each suite catches, use the coverage against mutation tool, and for what coverage does and does not predict, what the research actually says.
Questions
Modified Condition Decision Coverage requires that each condition inside a decision is shown by execution to independently and correctly affect the outcome of that decision. Showing it takes a pair of tests that differ in exactly that one condition and produce different outcomes, which is why this tool prints the pair rather than only a percentage.
n plus 1 for n conditions, in the general case, against 2 to the n for full multiple condition coverage. That linear cost is the entire reason MC/DC exists: it proves each condition's independent effect without the exponential blow-up of testing every combination.
Branch coverage only asks that the decision come out true once and false once, which two tests always satisfy however many conditions there are. Those two tests can change several conditions at once, so none of them is shown to independently drive the result, and a decision that ignores a condition entirely still passes.
That no test set anywhere can show it affects the outcome, because it genuinely does not. The condition is present in the source and cannot change the result. That is a defect in the expression rather than a gap in the tests, and it is usually a duplicated term, an inverted operator, or a clause somebody meant to delete.
DO-178C requires statement, decision and MC/DC at Level A, the catastrophic failure level, and drops to statement plus decision at Level B and statement alone at Level C. ISO 26262 makes MC/DC highly recommended at ASIL D. IEC 62304 scales verification rigor by software safety class rather than naming the criterion directly.