Learner can model simple state transitions and explain statement vs branch coverage at a basic level.
State transition testing and white-box coverage
Modeling behavior over time — and peeking inside the code
Some software behavior depends not just on the current input but on what happened before — the system's state. State transition testing models this as a state machine: a set of states, events that cause transitions between them, and guards or actions that accompany those transitions. A classic example is an online order: it starts in Placed, moves to Paid when payment succeeds, then to Shipped when dispatched, then to Delivered on receipt. At any point the customer or system may trigger Cancel — but only from states where that makes sense (Placed or Paid, not after Shipped). Testing should cover all valid transitions (the happy paths and legitimate branches) and attempt invalid transitions (e.g. shipping a cancelled order) to confirm the system refuses them.
A good state transition test set includes: at least one path through all states, every event from every state (to verify both acceptance and rejection), and critical negative paths where an invalid transition is attempted. State diagrams and state transition tables are the standard tools for documenting this.
White-box (structural) testing looks inside the code instead of treating it as a black box. Statement coverage measures what percentage of executable statements are executed by the test suite — a common minimum bar. But a statement can execute without testing both outcomes of an if/else. Branch coverage (also called decision coverage) requires that each branch — each true and each false path out of every decision point — is exercised at least once. A small example: if (discount > 0) { applyDiscount(); } else { fullPrice(); } — a single test with discount = 10 gives 100% statement coverage of the if-block, but 0% coverage of the else branch. To reach 100% branch coverage you need at least two tests: one where discount > 0 is true and one where it is false. Branch coverage is strictly stronger than statement coverage and is the more meaningful metric in practice.
Lesson notes
Modeling behavior over time — and peeking inside the code
Some software behavior depends not just on the current input but on what happened before — the system's state. State transition testing models this as a state machine: a set of states, events that cause transitions between them, and guards or actions that accompany those transitions. A classic example is an online order: it starts in Placed, moves to Paid when payment succeeds, then to Shipped when dispatched, then to Delivered on receipt. At any point the customer or system may trigger Cancel — but only from states where that makes sense (Placed or Paid, not after Shipped). Testing should cover all valid transitions (the happy paths and legitimate branches) and attempt invalid transitions (e.g. shipping a cancelled order) to confirm the system refuses them.
A good state transition test set includes: at least one path through all states, every event from every state (to verify both acceptance and rejection), and critical negative paths where an invalid transition is attempted. State diagrams and state transition tables are the standard tools for documenting this.
White-box (structural) testing looks inside the code instead of treating it as a black box. Statement coverage measures what percentage of executable statements are executed by the test suite — a common minimum bar. But a statement can execute without testing both outcomes of an if/else. Branch coverage (also called decision coverage) requires that each branch — each true and each false path out of every decision point — is exercised at least once. A small example: if (discount > 0) { applyDiscount(); } else { fullPrice(); } — a single test with discount = 10 gives 100% statement coverage of the if-block, but 0% coverage of the else branch. To reach 100% branch coverage you need at least two tests: one where discount > 0 is true and one where it is false. Branch coverage is strictly stronger than statement coverage and is the more meaningful metric in practice.