yoi/.yoi/objectives/00001KTNKDX3G/item.md

title	state	created_at	updated_at	linked_tickets
E2E テスト戦略	active	2026-06-09T07:09:26Z	2026-06-09T07:09:26Z	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 に置く。