最終更新: 2026/06/22 18:56
commonid: 03_webui_e2etype: how-tostatus: active

Web UI e2e テスト (chat.html)

Decision Pipeline の Web UI (drp/public/chat.html) のテストは 2 層構成 (毎 PR の mocked-route e2e + on-demand の実 LLM full-run) で運用する。 設計判断は ADR-0111 で確定。

一次情報 (SSoT): drp/test/e2e/README.md 2 層構成の比較表・実行コマンド・応答契約の運用 (契約→サーバ→モックの 3 点同時更新) はすべてここにある。 本ページは「いつどちらを使うか」の判断基準と参照ポインタのみを持ち、手順は重複記述しない。

いつどちらを使うか (判断基準)

状況使う層起動方法
chat.html / UI コードを変更する PRui/ mocked-routeCI が自動実行 (毎 PR ゲート)。ローカル先行確認は pnpm --filter drp run test:e2e:ui
API 応答形式を変更する PRui/ + 契約 3 点更新応答契約 src/contracts/chat_api_contract.ts → サーバ → モックを同 PR で更新。型ズレは CI の Mock contract type-check (type-check:e2e) が機械検知
API 応答形式の変更後・デプロイ経路の変更後・リリース前real/ 実 LLM full-runon-demand 手動実行 (SSoT README §real/ のコマンド)。本物の審査が走り課金されるため節目のみ
サーバ実応答とモック定義のズレ (値セマンティクス drift) が疑わしいときreal/型が同一のまま意味が変わる drift は mocked-route では検知できない (ADR-0111 §影響の許容リスク)

判断に迷ったら: CI が green でも実 LLM 検証は別物。型検査 (契約 satisfies) は形式 drift しか止めない。 意味の drift・統合全体の検証は real/ でしか確認できない。

CI ゲートの構成

  • ワークフロー: .github/workflows/drp-test.yml の ui-e2e job (毎 PR、実測 1m16s〜1m24s)
    • Playwright page.route() で全 API 応答をモック — LLM / Worker 不要・決定論的
    • Mock contract type-check step: サーバ/モック双方が chat_api_contract.ts を satisfies していることを tsc で強制 (PR #1383。導入時に既存モックの非現実 2 件を即検知)
  • real/ は CI 非ゲート (on-demand 温存)

関連

  • 変更時テストの対応表: リポジトリルート CLAUDE.md「変更時テスト」(chat.html 行 = PR #1377 で追加)
  • 実績: mocked-route e2e は導入当日に実バグを 1 件発見 (復元セッション + フォーム空で停止トグル無反応 → PR #1376 修正、BUG_tracking DRP-375)