Webシステムの「イベント」をテストする
UI, API, バッチ処理などなどWebシステムにおいてはさまざまな処理がありますが、蓋を開けてみるとだいたいどれも中身は似たようなものだったりします。つまり、インプットを受け取り、計算やDBへの保存などを経て、アウトプットを返すといったところです。
では、UI, API, バッチ処理の違いはなんなのか。大きな違いの一つは 「イベント」 です。
今回はどんなイベントがあるか、そして普段どのようにテストをしているかをまとめてみます。
イベントとは
ざっくり言うと、「処理を始めるきっかけ」 [1]です。わかりやすいところで言うと、
- ボタンのクリック
- フォームへの入力
などがそれに当たります。
イベントの種類
多種多様なイベントがあるので、以下の通り分類してみることにしました。
- UIの有無
- 要はブラウザ上の画面などを介すか介さないかです。
- 同期処理か、非同期処理か
- 同期処理はその処理が終わるまで次の処理に進めないこと、非同期処理は処理の完了を待たずに次の処理を進めることです。
これを組み合わせると次の表のようになります。
| 大分類 | 下位分類 | イベント例 |
|---|---|---|
| UIあり×同期 | - | ボタンのクリック、フォームへの入力 |
| UIあり×非同期 | - | 手動でのジョブ起動（管理者画面など） |
| UIなし×同期 | - | REST API/GraphQLなど[2] |
| UIなし×非同期 | 時間イベント | cron, Cloud Scheduler |
| UIなし×非同期 | 状態変化イベント | ステータス変更など |
| UIなし×非同期 | 外部イベント | Webhook, キュー, Pub/Sub |
他にもあるとは思いますが、普段関わることが多いのはこの辺りだと思います。
ここでのポイントは、「UIのないイベントが結構たくさんある」 ということです。
イベントの解説とテストのポイント
[UIあり×同期]ボタンのクリック、フォームへの入力
ユーザーが画面上で操作（クリックやキーボード入力）を行うと、その瞬間に処理が同期的に進む。
画面遷移や即時フィードバックを伴うことが多い。
テストのポイント
- 正しい入力／誤った入力に応じた反応をチェックする（バリデーションエラーなど）
- ボタン押下後の遷移先やレスポンスを確認する
- 連打、無効操作（入力中に戻るなど）も試す
- キーボード操作（Tab移動、Enter押下）も網羅する
起こりうるバグ（一例）
- バリデーション漏れ
- 二重送信（連打）による重複登録
[UIあり×非同期]手動でのジョブ起動（管理者画面など）
管理者画面などでユーザーが明示的に「ジョブ実行」ボタンなどを押すが、処理結果は即時ではなくバックグラウンドで進むパターン。
テストのポイント
- 起動指示が正しくサーバーに送られているかを確認
- ジョブの成功／失敗結果の通知タイミングと内容を検証
- ジョブ中のステータス表示（例：進行中マーク）が適切か
- ジョブ起動失敗時の表示や再試行機能も試す
起こりうるバグ（一例）
- 権限不足ユーザーでもジョブを起動できてしまう
- ジョブは成功しているのに、画面に反映されない
[UIなし×同期]REST API/GraphQLなど
画面を介さず、プログラムが直接リクエストを送ってレスポンスを待つ同期処理。APIを叩いたらすぐに結果が返る。
テストのポイント
- リクエスト先（URL)、メソッド（GETやPOST)、パラメータが正しいか確認する
- リクエストパラメータとレスポンスの整合性を確認
- 成功時・失敗時（400, 500系エラーなど）のレスポンスを網羅
- スキーマ（型・必須項目など）のバリデーションを意識
- 不正リクエスト・境界値リクエストも試す
起こりうるバグ（一例）
- エンドポイント名やメソッドが正しくなくてエラー
- 必須パラメータ未指定でもリクエストが通る
- 認可チェック漏れで本来アクセスできないデータが見える
[UIなし×非同期]時間イベント
cronジョブやスケジューラーによって、特定の時間・間隔で自動的に処理が発火するパターン。バッチ処理は大体これ。
テストのポイント
- 設定した時間通りにジョブが発火するか
- 時間帯による挙動の違い（深夜・月末・閏年など）を確認
- ジョブの処理結果やリトライ処理の検証
- システム障害時（ジョブ失敗・遅延）への耐性確認
起こりうるバグ（一例）
- 想定していた時間にジョブが実行されない（タイムゾーン設定ミス）
- 月末・閏年など特別な日付で処理失敗
[UIなし×非同期]状態変化イベント
DBのレコード更新やステータス変更など、内部状態の変化をトリガーに処理が自動発火するパターン。
テストのポイント
- 状態変更後、期待するイベントが正しく起きるか
- 想定外の状態変化（不正データなど）への耐性
- 状態遷移ルール（禁止されている遷移）を網羅的に確認
- 並列で複数変更された場合の整合性確認
起こりうるバグ（一例）
- 状態変更がトリガーにならず、イベントが発火しない
- 本来許されない状態遷移（例：未承認→完了）ができてしまう
[UIなし×非同期]外部イベント
他システムからのWebhook受信や外部バッチ連携など、システム外部からの入力によって発火するパターン。
テストのポイント
- 外部イベント受信の正常系・異常系（タイムアウト、再送など）を検証
- セキュリティ（認証・認可）周りの検証
- 受信データのフォーマット違いに対する堅牢性
- イベント受信後の内部処理フローまで追跡テスト
起こりうるバグ（一例）
- イベント受信後に処理が途中で止まる（再送設計なし）
- 受信データの形式が想定と違っていてパースエラー
終わりに
普段目につかないところでも結構色々な処理が走っているので、実装者にヒアリングしたり設計書を読んだり、場合によってはコードを読みながら進めるようにしています。
Discussion