Summary
この文書の要点
- E2Eは画面部品ではなく業務フロー単位で書く。
- ログイン、作成、更新、承認、検索など止められない流れを選ぶ。
- ログイン、作成、承認、出力など、業務上のクリティカルパスを先に選ぶ。
- テストデータ作成、待機条件、失敗時スクリーンショットを標準化する。
どこが設計の難所か
Playwrightを導入しても、すべての画面を細かくテストしようとすると保守できません。UIの微修正で壊れるテストが増えると、E2Eの信頼が下がります。
E2Eはブラウザ、ネットワーク、DB、認証に依存します。実行時間も長くなりがちです。PRごとに回すテストは、短時間で価値の高いものに絞る必要があります。
Playwrightはブラウザ操作を再現できますが、全画面を網羅しようとすると壊れやすく遅いテスト群になります。重要なのは、実際に業務が止まる導線を選び、少数でも信頼できる形で回すことです。
境界をどう切るか
まず、業務が止まると困るクリティカルパスを選びます。ログインできる、主要データを登録できる、検索できる、承認できる、権限外操作が拒否される、といった流れを優先します。
設計では、画面単位ではなく業務シナリオ単位でテストを作ります。ログイン、検索、登録、承認、ファイル出力のように、複数画面をまたぐ経路を1本のクリティカルパスとして扱います。
実装で効く細部
テストでは、APIやDBを使って前提データを作り、画面操作は利用者に近い手順にします。セレクタは見た目のclassではなく、roleやlabelを使います。テストごとにデータを分離し、並列実行に耐えるようにします。
実装では、テスト用ユーザー、seedデータ、APIによる事前準備、data-testid、待機条件を整えます。UIの見た目に依存したselectorを避け、操作の意味が残るlocatorを使うと保守しやすくなります。
- テストごとに独立したデータを作り、実行順序に依存しないようにする。
- network idleだけに頼らず、画面上の完了状態やAPI結果を待機条件にする。
- 失敗時にはtrace、video、screenshotを保存し、CI上で原因を追えるようにする。
壊れ方を観測する
CIでは、PR時に少数のクリティカルパスを実行し、夜間や手動で広い回帰テストを回します。失敗時にはスクリーンショット、動画、traceを保存し、原因を短時間で追えるようにします。
検証では、CIでの安定性を見ます。ローカルで通るだけでなく、遅い環境、並列実行、初回ログイン、権限違いでも期待通りに動くかを確認します。flakyなテストは本番品質への信頼を下げるため、放置しません。
捨てた選択肢とトレードオフ
E2Eで細かい分岐まで確認すると安心感は増えますが、実行時間と不安定さも増えます。入力検証や計算ロジックはVitestへ寄せ、E2Eは統合された流れの確認に集中する方が保守しやすいです。
E2Eテストは単体テストより遅く、失敗原因も広くなります。だからこそ数を絞り、業務影響の大きい経路に集中するべきです。細かい分岐はコンポーネントテストやAPIテストへ逃がすとバランスが取れます。
現場に残す判断軸
Playwrightは画面の全自動確認ではなく、業務継続に必要な流れを守る道具です。最初の数本を慎重に選ぶことで、少ないテストでも大きな安心を得られます。
Playwrightは網羅率を競う道具ではありません。業務上止めてはいけない流れを実ブラウザで守るために使うと、少ない本数でも大きな効果が出ます。
