失敗したE2Eテストを、本物のブラウザで見ながら直す

## テストの前に、ブラウザで見える成功の形を決める E2Eテストを実行する前に、求められる動作を実ブラウザで観測できる条件へ変換する。開始URLまたはルート、必要なアカウントまたはフィクスチャの状態、関係する場合はビューポート、ユーザー操作、成功を示す正確な表示結果を記録する。アクセシビリティの状態、画面遷移、永続化された状態、ネットワーク経由のコンテンツが動作の一部なら、それらも含める。 - スタイル用クラスやDOM上の位置より、安定したユーザー向けの役割、ラベル、専用のテスト識別子を優先する。 - テストランナーの画面とテスト対象アプリを区別する。一方の証拠が、もう一方の状態も自動的に表すとは限らない。 - 確認表示や値の変化などの肯定的な証拠と、エラーバナーがないことなどの否定的な証拠の両方を定義する。 - タイミング要件は、任意の待ち時間ではなく、観測可能な準備完了条件で表す。 テストを通すためだけにアサーションを弱めてはならない。期待動作が曖昧なら作業を止め、テストコードまたは製品コードを変更する前に受け入れ条件を明確にする。 ## 本物のブラウザでテストを動かし、スクリーンショットとログを残す 通常のアプリ経路を使い、実際に対応しているブラウザで、関係する最小範囲のE2Eシナリオを起動する。設定、フィクスチャデータ、認証状態、ビューポート、機能フラグを、同じ実行を再現できる程度まで明示する。表示状態やブラウザ操作が重要で、GUI表示モードまたはデバッグモードを使える場合は、そのモードを使う。 失敗したら、何かを編集する前に次の証拠を記録する。 - 失敗したシナリオと、正確なアサーションまたはコマンド - 失敗時のブラウザのスクリーンショットまたはスナップショット - アクセシブル名と状態を含む、対象要素周辺のアプリDOM - 関係するブラウザコンソールエラーと、失敗または想定外となったネットワークリクエスト - 現在のURL、リダイレクト、読み込み表示、アプリ上に見えるエラーメッセージ - 利用できる場合は、サーバーログとの照合に必要な時刻または実行ID 無関係な状態を大量に取得せず、対象を絞って調べる。安定した失敗と一時的な失敗を区別する必要がある場合は、同じ条件で一度再現する。ただし、上限のない再試行ループは始めない。 ## 失敗の原因を、テスト・コード・環境のどれかに分ける 観測した失敗を、テスト原因、実装原因、環境原因のいずれかに分類する。分類はブラウザの証拠で裏付け、必要な場合に限り、関係する最小範囲のソースまたはログを調べて補強する。 - テスト原因: 製品は受け入れ条件どおりに動作しているが、テストが古いセレクタ、誤ったアサーション、無効なフィクスチャ、誤った操作順序、不十分な準備完了条件を使っている。 - 実装原因: コントロールが反応しない、状態や画面遷移が誤っている、アクセシビリティが後退している、製品コードが原因でアプリのリクエストに失敗するなど、ユーザーに見える動作が受け入れ条件に反している。 - 環境原因: テストと実装は正しい可能性があるが、利用できないサービス、無効な認証情報、非対応ブラウザ、不足している初期データ、誤った設定、資源不足など、前提条件が欠けているか正常でない。 証拠が混在する場合は、競合する仮説を書き出し、仮説を判別できる確認を一度に一つずつ実行する。すべてのタイムアウトをテストの問題と決めつけず、テストが失敗したという理由だけで製品コードを変更しない。証拠によって最も近い別の可能性を除外できるまで、分類は暫定扱いにする。 ## アサーションを弱めずに、原因に合わせていちばん小さく直す 広範なリファクタリングをせず、分類した原因に対処する修正を選ぶ。受け入れ条件と、失敗経路の外にある既存のユーザー動作を維持する。 - テスト原因なら、観測したブラウザ状態と矛盾するセレクタ、アサーション、フィクスチャ、操作順序、準備完了条件だけを更新する。 - 実装原因なら、可能な場合は失敗する回帰テストを追加または維持してから、指定動作の復旧に必要な最小範囲の製品ロジックだけを変更する。 - 環境原因なら、不足している前提条件を修復または文書化する。待ち時間の延長、アサーションの無効化、無条件の再試行で隠してはならない。 - 固定時間の待機より、画面上の準備完了、リクエスト完了、安定した状態などの決定的な合図を優先する。 - テストしやすくする変更はユーザー動作に影響させない。偶然のレイアウトへテストを結び付けず、安定した識別子またはアクセシブルなラベルを追加する。 保護対象、生成物、本番、破壊的操作を伴うもの、認証情報を含むものを編集する前に作業を止め、必要な許可を得る。テスト、ログ、スクリーンショット、フィクスチャ、報告へ秘密情報を絶対に露出させない。 ## 同じシナリオを再実行し、失敗が続いたら止める 修正後、同じブラウザ条件と受け入れ条件で、失敗したシナリオをそのまま再実行する。ブラウザが定義済みの成功状態へ目に見える形で到達し、テストランナーが隠れた失敗を報告していない場合だけ合格とする。コンソールまたはネットワークの証拠が診断に使われた場合は、原因となったエラーがそこに残っていないことも確認する。 次に、周辺シナリオ、機能ファイル、密接に関係するテストグループなど、直接影響を受ける最小の回帰確認範囲を実行する。変更の影響が広い場合、またはユーザーが明示的に求めた場合を除き、無関係な全テストへ範囲を広げてはならない。再実行が別の形で失敗したら、推測による修正を重ねず、証拠の記録と分類へ戻る。 繰り返し回数を制限する。同じ方法で2回修正しても効果がなければ診断を見直し、別の判別確認を選ぶ。新しい証拠がないまま3回連続で失敗したら、コードベースの変更を続けずに停止し、阻害要因を報告する。 ## 合格か失敗か、行き詰まったかを、証拠つきで最初に伝える 元のブラウザ観測可能な受け入れ条件に合格し、直接影響を受ける回帰確認範囲にも合格し、関係する原因エラーが残っていない場合だけ、成功として停止する。作業の続行に、不足している権限、認証情報、利用できない基盤、破壊的操作、安全に推測できない製品判断が必要な場合も停止する。 他の人が検証できるだけの証拠を添えて、結果を報告する。 - 使用したシナリオとブラウザ条件 - 観測した失敗とその分類 - 分類を裏付けた証拠 - 実施した最小変更、または未解決の前提条件 - 実施した正確な再実行内容と結果 - 残るリスク、省略した広範な確認、次に必要な対応 合格、失敗、阻害中のいずれかを最初に示す。成功条件が実ブラウザに依存する場合、コード確認だけ、単体テストの合格だけ、模擬DOMだけで完了を宣言してはならない。