---
title: "E2E テスト戦略"
state: "active"
created_at: "2026-06-09T07:09:26Z"
updated_at: "2026-06-09T07:09:26Z"
linked_tickets: ["00001KSKBP9YG"]
---

## Goal

Yoi の実プロセス・実 socket・実 provider 境界をまたぐ振る舞いを、通常の crate 内 unit / integration test だけに頼らず検証できる E2E テスト戦略を確立する。

最初の到達点は、実 `pod` / product binary を spawn し、protocol 経由で最小シナリオを実行し、graceful shutdown まで確認できる opt-in E2E harness を持つこと。その上で、permission、resume/fork、spawned Pod、provider stream、TUI/Panel などの重要境界を段階的に増やせる状態にする。

## Motivation / background

現状のテストは crate 内の in-process coverage が厚い一方で、以下の性質は単体テストだけでは十分に確認しづらい。

- 実プロセス spawn と runtime dir / socket / env の相互作用。
- Pod controller / protocol client / session store / metadata / restore の統合挙動。
- provider endpoint、streaming、auth/token、tool call、continuation、retry の実接続に近い振る舞い。
- permission deny、scope、manifest/profile 解決、child Pod delegation など、複数 crate と実 runtime state をまたぐ policy。
- TUI / Panel が前提にする Pod lifecycle や Ticket orchestration の外形。

E2E は常時実行の軽いテストではなく、dogfooding 中に「この機能は実 runtime でも壊れていない」と確認するための opt-in 検証基盤として必要。

## Strategy / design direction

- E2E は通常の `cargo test --workspace` からは外し、明示 feature / 専用 package / 独立 job で opt-in 実行する。
- まずはワークスペース直下の専用 E2E package / harness として設計し、個別 crate の unit test に押し込めない。
- protocol を喋る側は TUI の PTY 操作ではなく、typed client / protocol client を使う方向を優先する。
- provider 依存は最初から全部を対象にしない。
  - 最小 harness では canned / fixture / mock HTTP server を使う。
  - provider 差分は代表 provider から段階的に増やす。
- env / runtime dir / socket path は test ごとに隔離し、並列実行方針を明示する。
  - 必要なら最初は `--test-threads=1` 相当で安全側に倒す。
  - 将来的には per-test runtime dir と typed launch config で並列性を上げる。
- E2E は「全シナリオを大量に持つ」より、重要な runtime seam ごとに少数の高価値 scenario を置く。
- 失敗時 diagnostics は、secret を出さずに process phase、socket path、session id、log path、provider fixture id を辿れる形にする。
- E2E harness 自体が flaky にならないよう、network / time / external auth への依存は明示 opt-in に分ける。

## Success criteria / exit conditions

- `cargo test --workspace` では E2E が走らず、通常開発の feedback loop を重くしない。
- 明示コマンドで E2E harness を実行できる。
  - 例: `cargo test -p e2e --features e2e` または後続で決める同等コマンド。
- 最小 scenario が実 `pod` / product binary を spawn し、protocol 経由で 1 turn 実行し、graceful shutdown まで通る。
- E2E 実行は専用 runtime/data dir を使い、通常の user/workspace state を汚さない。
- fixture / mock provider の設計があり、少なくとも 1 provider 相当の canned response を実 HTTP 経由で返せる。
- failure diagnostics から、spawn 失敗・socket 接続失敗・provider fixture 失敗・protocol 失敗・shutdown 失敗を区別できる。
- 後続 Ticket が permission / resume / fork / spawned Pod / provider streaming / Panel などを追加できる harness boundary がある。

## Decision context

- linked Ticket `00001KSKBP9YG` は、E2E harness の最初の concrete implementation Ticket として扱う。
- この Objective は E2E 全体の中長期方針・判断軸を保持する。個別 scenario の実装や harness の細部は concrete Ticket に分ける。
- TUI を直接 PTY で叩く方針は初期 harness では避け、protocol/client 経由を優先する。
- provider 全対応は初期 scope にしない。fixture / mock HTTP server を基礎にし、代表 provider から段階的に広げる。
- E2E は flakiness と実行コストが高いため、既定 CI / 既定 workspace test には入れず、opt-in 検証として始める。
- Objective context は判断材料であり、実装 authority は各 Ticket の body/thread/artifacts と明示的な Ticket relation / OrchestrationPlan に置く。