Модуль 3 · Урок 11
State transition testing і coverage
Однаковий event може мати різний outcome залежно від current state, guard і history. State model допомагає тестувати sequences, invalid transitions та side effects, які одиничний input/output case не показує.
Модель поведінки
Нотація `event [guard] / action` змушує відділити event від умови. State table часто корисніша за diagram для QA, бо порожні cells роблять invalid transitions видимими.
BookFlow booking lifecycle
| Source | Event [guard] | Action | Target |
|---|---|---|---|
| Draft | submit [data valid] | create hold | Held |
| Held | payment_success [not expired] | confirm | Confirmed |
| Held | timeout | release inventory | Expired |
| Expired | payment_success | reject late callback | Expired |
Останній рядок — invalid business transition, але event технічно може надійти асинхронно. Oracle має перевірити незмінність state, відсутність capture/resurrection і audit evidence.
Три coverage criteria
Valid-transition coverage сильніша за all-states. Один test sequence може покрити кілька valid transitions, але precondition/start state та evidence повинні бути відтворюваними.
Race, retry і time
State testing для Web/API має враховувати duplicate callbacks, retry, event reordering, timeout boundary та concurrent users. Використовуйте controlled clock/idempotency key у дозволеному стенді. Ніколи не імітуйте payment callback на чужому production.
Практика
Заповніть `state-model.csv` і `transition-tests.csv`: start state, sequence, guards, expected states/actions, coverage items, evidence та limitation.
Офіційне джерело
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.