外部決済・OAuth・カスタマーポータルのように、アプリ操作後に外部サービスへリダイレクトするフローは、E2E で外部ページそのものを追うと不安定になりやすく、モック検証の価値も薄くなる。

判断基準:

• 自アプリの責務は、正しい画面状態から正しい API を呼ぶこと、必要な request body を送ること、API が返した URL へ遷移を開始することまで。
• 外部サービス画面の UI、カード入力、認証、決済完了 webhook などは外部システムまたは統合テストの責務に分ける。
• E2E では外部ドメインへ実アクセスせず、ローカルのモック URL を API レスポンスとして返し、その URL へ遷移したことを確認する。
• window.location.href のような副作用は小さな関数へ切り出し、単体テストで「API 成功時に返却 URL が渡る」ことを固定すると、E2E 側は画面導線と API 境界に集中できる。

検証観点:

• 遷移前の画面状態が期待どおり表示される。
• click で発生した API request の method/body が期待どおり。
• API が返すローカル URL へ実際に navigation する。
• 外部サービスの本物の画面にはアクセスしないため、CI でネットワーク・認証・外部 UI 変更に影響されない。

適用範囲: 決済 checkout、顧客管理 portal、OAuth consent、外部 SSO など、アプリ境界を越えるリダイレクト型フロー全般。