Learning Objectives
By the end of this lesson you will be able to:
- Define state, event, transition, and guard as components of a state machine
- Identify the life cycle states of a real-world entity from a specification
- Explain why state transition testing complements other black-box techniques
Everything Has a State
Open your email client. An email is Unread, then Read, then maybe Archived or Deleted. Each of those is a state — a condition the object can be in at a given time.
A user account can be Active, Suspended, or Closed. A payment can be Pending, Authorized, Captured, Refunded, or Failed. An order can be Created, Confirmed, Shipped, Delivered, or Cancelled.
Every non-trivial object in software has a state model. And every state model has transitions that need to be tested.
The Four Components
State — a recognizable condition that persists over time. An order that has been placed but not yet confirmed is in the Confirmed state (not a moment, but a period).
Event — an action or trigger that causes a transition. "User clicks Pay" is an event. "24 hours pass without payment" is an event.
Transition — the movement from one state to another, triggered by an event. The arrow on a state diagram.
Guard — an additional condition that must be true for a transition to proceed. "Cancel order" can only happen if order.status != 'Shipped'. Guards make certain transitions conditional.
A Real Example: Task Management
States: Draft, In Progress, In Review, Done, Cancelled
Some transitions:
- Draft + "Start work" → In Progress
- In Progress + "Submit for review" → In Review
- In Review + "Approve" → Done
- In Review + "Request changes" → In Progress
- Any state + "Cancel" → Cancelled (with guard: cannot cancel if Done)
What State Testing Covers
State transition testing focuses on three things:
- Valid transitions — does the system correctly move from State A to State B when the trigger event occurs?
- Invalid transitions — does the system correctly reject a move from State A to State C when that transition is not in the model?
- Guard conditions — does the guard correctly allow or block a transition based on its condition?
Pro Tip: The most valuable tests are the invalid ones. A developer typically codes the happy path (valid transitions) and leaves invalid transitions either silently ignored or crashing. Testing an invalid transition reveals whether the system has proper guard logic or just falls through.
State Coverage vs. Transition Coverage
State coverage: every state has been visited in at least one test. Easy to achieve, low confidence.
Transition coverage: every valid transition has been exercised at least once. Better. This is the standard minimum.
Invalid transition coverage: every invalid transition has been attempted and rejected. This is where the real bugs are.
Summary
Every entity with a meaningful lifecycle is a candidate for state transition testing. The framework — states, events, transitions, guards — gives you a complete vocabulary for describing what the system can and cannot do. In the next lesson, you'll systematically test which transitions the system correctly allows and which it correctly blocks.