How do all-states and all-transitions criteria differ when a generator emits paths from a behaviour model?

## Why a criterion is needed at all Any behaviour model with a cycle admits infinitely many walks: a billing run that can be disputed, adjusted and disputed again has no longest path. A generator therefore cannot simply enumerate; it needs a rule that says *which finite set of paths counts as enough*. That rule is the **selection criterion**, and it is the single knob that decides both how much the generated suite finds and how long it takes to run. Note what kind of coverage is under discussion. This is coverage of the model — how much of the described intent the emitted paths exercise. It is not line or branch coverage of the implementation, and the two numbers are unrelated: a model can be fully traversed while large parts of the code never execute, and code coverage can be high while an entire region of intended behaviour was never modelled. ## All-states The emitted set of paths satisfies **all-states** when every state named in the model has been entered at least once. For the utility billing run model with nine states — Draft, ReadingsLoaded, Estimated, Validated, Invoiced, Disputed, Adjusted, Settled, Cancelled — three paths of six to eight steps are usually enough. It is the cheapest useful criterion and the weakest. Its blind spot is that a state can be reached one way and never any other. If cancel is legal from six different states but the generated set only ever cancels from Draft, the criterion is satisfied while five cancellation routes were never taken — and those are exactly where the interesting faults live, because each one has different cleanup to do. ## All-transitions **All-transitions** requires every legal edge — every (state, action) pair the model permits — to be taken at least once. It subsumes all-states, since entering a state requires an edge into it, and it plugs the blind spot above: all six cancellations get exercised. It is the criterion most teams adopt as their routine bar, because it is the cheapest one that can detect the two faults a state machine is most prone to: an action that leads to the wrong destination state, and an action the code accepts although the model forbids it. For the nine-state, 17-transition billing model, a well-packed set covers all 17 in about seven paths and roughly forty steps — still small enough to run on every change. A generator producing such a set is solving a route-inspection problem: find a walk, or a small set of walks, traversing every edge at least once. Solved properly, it yields far fewer and longer paths than a naive generator that restarts from the initial state to reach each uncovered edge in turn. Both satisfy the criterion; they differ in run time and in how readable a failure is. ## Beyond all-transitions Several stronger bars are in common use. - **Guard coverage**: every guard evaluated both true and false, so the rejection paths are exercised, not just the happy edges. On the billing model this is what produces cases like issuing an invoice from Draft and expecting refusal. - **Transition-pair coverage**: every legal pair of consecutive transitions, which catches faults that depend on the immediately preceding action rather than only on the current state. - **Bounded loop repetition**: each cycle taken zero, one and two times, which is how a generated set finds the accumulation faults — the second adjustment on a disputed invoice behaving differently from the first. Cost climbs sharply. Adding guard coverage to the billing model took the generated set from about seven paths to 214, and transition pairs would take it well past a thousand. That is why criteria are usually tiered: all-transitions on every change, the stronger criterion nightly with a path budget and a time cap. ## Picking one in practice Three questions decide it. How long may the generated set take to run — a criterion that produces a suite nobody waits for is not a criterion, it is a backlog item. What kind of fault are you hunting — wrong destinations argue for all-transitions, order-dependent faults for transition pairs, accumulation faults for loop bounds. And how coarse is the model — an abstraction so coarse that eleven real behaviours collapse into one state will report a satisfied criterion while leaving ten of them untried, which is the failure mode that makes model coverage numbers dangerous to quote to anyone outside the team. The honest summary in an interview: name the criterion, say what it subsumes, give its blind spot, and be explicit that satisfying it is a statement about the model's completeness of traversal and never a statement about the system being correct.