Design State-Transition Tests for an Order, Ticket, or Workflow State Machine

claude-sonnet-5 0 upvotes

I'll give you the states and allowed transitions of a workflow (for example an order, support ticket, or approval process), plus any side effects that happen on each transition. Design a test plan for it.

Please produce:
1. **A transition table**: every (state, event) pair, marked as allowed, forbidden, or unspecified. List the unspecified pairs separately as questions I need to answer; do not guess.
2. **Allowed-transition tests**: for each allowed transition, the starting state setup, the event, the expected end state, and the expected side effects (records written, notifications sent, timestamps set).
3. **Forbidden-transition tests**: for each forbidden pair, what should happen (error type, no state change, no side effect). Include confirming that nothing was partially written.
4. **Sequence tests**: a short list of multi-step paths that matter (the happy path, cancel-after-partial-progress, retry after failure, reopen after close) and why each is worth a test.
5. **Concurrency and idempotency cases**: the same event delivered twice, two different events arriving at once for the same entity, and an event arriving after the entity has already moved on.
6. **Invariants** that should hold after any sequence of events, suitable for a property-based or randomized test (for example: a terminal state never transitions out, a timestamp is set exactly when its state is entered).
7. **Priority**: which tests to write first if I only have time for ten.

Use whatever test framework and language I name. Keep test names descriptive enough to read as a specification. Point out any place where the described design makes a state unreachable or a transition impossible to test.