skip to content

In state transition testing, what is the difference between 0-switch and 1-switch coverage?

level: middleimportance: must knowfreq 57%

answer

  1. Chow's counting family for state models
  2. N counts switches, not transitions
  3. Every arrow once versus every legal pair
  4. Sum of out-degrees of each target state
  5. Catches route-dependent, carried-over data

basics

~10 s

0-switch coverage exercises every single valid transition at least once. 1-switch coverage exercises every valid pair of consecutive transitions, so it catches defects that only appear when one move follows another.

solid answer

~50 s

**0-switch coverage** (also called Chow's N-switch with N=0, or simply transition coverage) requires that every valid transition in the model is taken at least once. One arrow, one case. **1-switch coverage** requires every valid *pair* of consecutive transitions — every arrow followed by every arrow that can legally follow it. The count grows fast: a ledger model with 10 transitions has 14 legal pairs, and a denser model grows far worse, because the pair count is the sum of the out-degrees of each transition's target state. The payoff is defects that need history: a state entered by one route behaves differently than the same state entered by another, because the implementation carried a stale flag or a lingering resource in. In practice teams take 0-switch across the whole model as the baseline and 1-switch only on the high-risk region, because N-switch cost climbs roughly geometrically with N.

code

pseudocode · 14 lines
pseudocode
MODEL: 6 states, 7 events, 10 specified arrows

0-switch  (10 cases, one arrow each)
  Reserved --pick--> Picked

1-switch  (14 cases, one legal pair each)
  Reserved --pick--> Picked --ship--> Shipped
  Reserved --pick--> Picked --cancel--> Cancelled

pairCount = SUM over arrows a OF outDegree(target(a))
          = 4 + 4 + 0 + 0  (arrows into Draft / Reserved / terminals)
          + 2 + 4 + 0 + 0
          + 0 + 0
          = 14

go deeper

for a junior

Recall the two definitions cleanly: 0-switch takes every valid transition once, 1-switch takes every valid pair of consecutive transitions. Be able to count the 0-switch cases for a small drawn model.

for a middle

Explain the counting rule for pairs — the sum of out-degrees of each arrow's target — and why terminal states contribute nothing. Name the history defect that 1-switch catches and 0-switch cannot.

for a senior

Show where you would spend the extra runs: regions that allocate or release resources, or carry an amount forward. Talk about long walks versus short cases and what that does to failure diagnosis.

for a principal

Own the policy: 0-switch as a non-negotiable floor across the model, higher N bought deliberately on risk. Be ready to justify that stance on cost, run time and how quickly a failure can be localised.

### The idea of switch coverage Once behaviour is drawn as states and arrows, "how much have we tested?" becomes a counting question, and the family of answers is called **N-switch coverage** (after Chow's work on testing from finite state machines). N counts the *switches* between transitions in a single test sequence: N=0 means each sequence exercises one transition, N=1 means each sequence exercises two transitions in a row, N=2 means three in a row, and so on. The name trips people up: 0-switch does not mean zero transitions, it means zero switches *between* transitions. ### 0-switch coverage The requirement is that every valid transition in the model is taken at least once by some test. Take the warehouse stock ledger with six states — Draft, Reserved, Picked, Shipped, Cancelled, Expired — and ten specified arrows. 0-switch coverage is ten cases. Each one drives the row into the source state, fires the event, and asserts the target state and the action. This is the honest baseline, and it is cheap, but it has a blind spot. It says nothing about *how you got into* the source state. If Cancelled behaves correctly when reached from Draft but leaves a hold behind when reached from Picked, and your single cancel-from-Picked case happens to be the one you wrote, you were lucky rather than covered. ### 1-switch coverage The requirement is that every valid *pair* of consecutive transitions appears in some test sequence. Formally, for each transition T ending in state S, you need one sequence containing T followed by each arrow leaving S. So the pair count is the sum, over all transitions, of the out-degree of the transition's target state. On the ledger model that arithmetic gives fourteen pairs: the four arrows into Draft-or-Reserved states each fan out again, while the arrows into the three terminal states contribute nothing because nothing leaves Shipped, Cancelled or Expired. Fourteen sequences, each two transitions long, is a very affordable step up from ten. On a denser model — every state reachable from every other — the same arithmetic explodes, which is why nobody writes 2-switch or 3-switch suites by hand. The defects 1-switch finds are *history* defects. Entering a state twice by different routes should be indistinguishable; when it is not, some carried-over data is leaking. A ledger row that was amended before being reserved kept a stale line count that a directly-reserved row did not have — you find that only by testing the amend-then-reserve pair, never by testing each arrow alone. ### Choosing N Higher N is strictly stronger and strictly more expensive. Two practical rules: 1. **0-switch everywhere is the floor.** A model with an untaken arrow means a specified behaviour nobody ran. That is not a coverage debate, that is a gap. 2. **1-switch where history is plausible.** Regions that allocate or release a resource, that carry an amount forward, or that involve compensation and reversal are where pairs matter. Regions that are pure navigation rarely repay it. A generator that walks the model can emit sequences for any N, which shifts the cost from writing cases to running and diagnosing them; a failed twelve-step sequence tells you far less about *where* the defect is than a failed two-step one. That diagnosis cost is the real ceiling on N, more than machine time. ### Counting honestly Two counting traps recur in interviews. First, **only valid pairs count** — a sequence that is legal in the model, not any two arrows you can name. Second, **one sequence can satisfy several requirements**: a four-transition walk covers three pairs at once, so a well-chosen set of long walks meets 1-switch with far fewer than fourteen separate tests. Optimising for the fewest walks makes the suite shorter and each failure harder to localise, which is a real trade rather than a free win. ### What switch coverage does not tell you It is coverage of the *model*, not of the code and not of the specification. If the model is missing an event, no N makes the suite find defects in that event's handling. If the implementation has an arrow the model never drew, switch coverage will never walk it. Both of those are checked by other means — reviewing the event list against the requirements, and probing the combinations the model says are undefined. Switch coverage answers exactly one question: how much of the behaviour we *drew* have we walked?

  • Can one long test sequence satisfy several 1-switch requirements at once?
    Yes. A walk of four consecutive transitions covers three adjacent pairs, so a small set of well-chosen walks can meet 1-switch with far fewer than one test per pair. The trade is diagnosis: when a nine-step walk fails you know only that something in it broke, while a two-step case names the pair. Long walks for cheap coverage, short ones for the risky pairs, is the usual compromise.
  • Why does nobody build a 2-switch or 3-switch suite by hand?
    The requirement count climbs roughly geometrically with N, because each extra switch multiplies by the branching factor of the states you pass through. Even a modest model reaches hundreds of triples. Beyond that the sequences get long enough that a failure localises poorly and setup time dominates. If you genuinely need deep sequences, generate them from the model and accept that you are buying breadth at the cost of diagnosability.
  • What kind of defect does 1-switch catch that 0-switch cannot?
    History defects: a state that behaves differently depending on the route taken into it. Typically some carried-over data — a stale counter, an unreleased resource, a flag set by the earlier arrow — survives the transition. Every individual arrow passes, and the pair fails. If a state's behaviour genuinely depends on how it was entered, that is either a missing state in the model or a defect in the implementation.

saying these in an interview costs you the question

  • Thinking 0-switch means zero transitions tested
  • Counting all arrow pairs, not only legal consecutive ones
  • Claiming 1-switch is always the right target
  • Assuming higher N grows the case count linearly
  • Treating model coverage as code coverage
  • Ignoring that one walk can satisfy several pairs

context

resolving links…