状態遷移テスト（State Transition Testing）

状態遷移テストは、システムの応答が現在の入力だけでなく、それ以前に起きたことにも左右される場合に使います。システムを、状態の集合、状態間の遷移を引き起こすイベント、そして各遷移に伴うアクションやガード条件としてモデル化します。そのうえで、有効な遷移をテストし、同じくらい重要なこととして、無効な遷移が拒否されることを確認します。

例：ログインのロックアウト

アカウントはパスワードを 3 回連続で間違えるとロックされ、ログインに成功するとカウントがリセットされます。

状態：Active (0 failures)、1 failure、2 failures、Locked、Logged in。

現在の状態	イベント	次の状態
Active (0)	誤ったパスワード	1 failure
Active (0)	正しいパスワード	Logged in
1 failure	誤ったパスワード	2 failures
1 failure	正しいパスワード	Logged in（カウントをリセット）
2 failures	誤ったパスワード	Locked
2 failures	正しいパスワード	Logged in（カウントをリセット）
Locked	正しいパスワード	Locked（拒否）
Locked	管理者によるロック解除	Active (0)

ここから導かれるテスト：

1. すべての有効な遷移を少なくとも 1 回（0 スイッチカバレッジ）。誤り、誤り、誤りで Locked になる。誤り、正しいで Logged in になる。
2. 無効または想定外のイベント: ロックされたアカウントでは、正しいパスワードでも拒否されなければなりません。セキュリティのバグが潜むのはここです。
3. シーケンス: 誤り、正しい、ログアウト、その後に誤り、誤り。カウントは本当にリセットされているでしょうか、それとも 2 回目の失敗でロックされてしまうでしょうか？連続する 2 つの遷移のペアをテストすることを 1 スイッチカバレッジと呼びます。

適用できる場面

ライフサイクルを持つものすべてです。注文（作成、支払い済み、出荷済み、配達済み、キャンセル、返金）、バグのワークフロー、サブスクリプション、文書の承認、決済のステータス、メディアプレーヤー、UI のウィザードなどです。各状態について確認すべき問いは、この状態でどのイベントが許可されているか、許可されていないイベントはどうなるか、そしてブラウザーの戻るボタンや API の直接呼び出しなど、想定外の経路でこの状態に到達できないか、です。

よくある間違い

• ハッピーパスだけをテストする。 作成、支払い、出荷は 1 つの経路にすぎません。出荷後に注文をキャンセルできてしまわないか？2 回返金できてしまわないか？
• UI 経由でしかテストしない。 UI ではキャンセルボタンが隠されていても、API はそのリクエストを受け付けるかもしれません。遷移は API レベルでもテストしましょう。
• 状態遷移表を作らない。 状態遷移図は何が起きるべきかを示しますが、すべての状態とすべてのイベントを掛け合わせた完全な表を作ると、振る舞いが定義されていない抜けが見えてきます。