統合テスト・E2Eテスト設計・実装ルール

References

• references/e2e-design.md — E2Eテスト設計原則（候補ソース、選定基準、UI Specからのマッピング）
• references/e2e-environment-prerequisites.md — E2E環境前提条件（seed data、auth fixture、環境チェックリスト）

テスト種別と上限

*.int.test.ts

*.e2e.test.ts

クリティカルユーザージャーニー: 収益影響・法的要件・大多数のユーザーが日常的に利用する機能

振る舞い優先の原則

観測可能性チェック（全てYESで対象）

Include/Exclude基準

Include: ビジネスロジック正確性、データ整合性、ユーザー可視機能、エラーハンドリング Exclude: 外部実接続、パフォーマンス指標、実装詳細、UIレイアウト

スケルトン仕様

必須コメント形式

各テストに以下のアノテーションを含めること。

// AC: "[受入条件原文]"
// ROI: [0-100] | ビジネス価値: [0-10] | 頻度: [0-10]
// 振る舞い: [トリガー] → [処理] → [観測可能な結果]
// @category: core-functionality | integration | edge-case | ux | e2e
// @dependency: none | [コンポーネント名] | full-system
// @complexity: low | medium | high
// @real-dependency: [コンポーネント名]（任意、テスト境界で非モックセットアップが指定された場合）
it.todo('[AC番号]: [テスト名]')

Property注釈

// Property: `[検証式]`
// fast-check: fc.property(fc.[arbitrary], (input) => [不変条件])
it.todo('[AC番号]-property: [不変条件記述]')

マルチステップユーザージャーニーの定義

以下の3条件をすべて満たす場合、その機能にはマルチステップユーザージャーニーが含まれる:

1. 2つ以上の異なるインタラクション境界をユーザーゴール達成のために順番に通過する。何が境界に該当するかはシステムタイプによる:
   • Web: 異なるルート/ページ
   • モバイルネイティブ: 異なる画面/ビュー
   • CLI: 異なるコマンド呼び出しまたは対話型プロンプト
   • API: トランザクションを形成する異なるAPI呼び出し（例: 作成 → 確認 → 確定）
2. ステップ間で状態が伝搬する — あるステップで生成されたデータや実行されたアクションが、次のステップの受け入れや表示に影響する
3. ジャーニーに完了ポイントがある — ユーザーまたは呼び出し元が到達する最終状態（例: 確認ページ、保存されたレコード、API成功レスポンス、完了したワークフロー）

ユーザー向け vs サービス内部の分類

マルチステップジャーニーはE2E予算判断のためにさらに分類される:

この分類のスコープ:

• E2E予約スロット: ユーザー向けジャーニーのみが対象。サービス内部ジャーニーは予約スロットから除外される。
• 通常のROI > 50パス: ユーザー向け・サービス内部の両方が追加E2Eスロット（最大1件）をROI実績で競う。この分類はこのパスに影響しない。
• E2Eギャップチェック: ユーザー向けジャーニーのみがgap警告をトリガーする。サービス内部ジャーニーはトリガーしない。

ROI計算

ROI Score = Business Value × User Frequency + Legal Requirement × 10 + Defect Detection（範囲: 0–120）

ROI Scoreは同一テスト種別内での優先順位付けに使用する（統合テスト同士、E2Eテスト同士）。テスト種別間の比較には使用しない。統合とE2Eの予算は独立して選択されるため、種別間比較は不要。

ROI Scoreが高い = 同一テスト種別内での優先度が高い。正規化やキャッピングは適用しない — 生のスコアをそのままランキングに使用する。重複排除は候補自体を除外する別のステップであり、スコアは変更しない。

E2EのROI閾値

E2Eテストは所有コストが高い（作成・実行・保守それぞれが統合テストの3〜10倍）。予約スロット（ユーザー向けマルチステップジャーニー）を超える追加E2Eスロットには ROI Score > 50 が必要。

ROI計算例

実装ルール

Property-Based Test実装

Property注釈がある場合、fast-checkライブラリ必須:

import fc from 'fast-check'

it('AC2-property: モデル名は常にgemini-3-pro-image-preview', () => {
  fc.assert(
    fc.property(fc.string(), (prompt) => {
      const result = client.generate(prompt)
      return result.model === 'gemini-3-pro-image-preview'
    })
  )
})

必須事項:

• fc.assert(fc.property(...))

  形式で記述
• スケルトンの

  // fast-check:

  コメントをそのまま実装に反映
• 失敗ケース発見時は具体的なユニットテストとして追加（リグレッション防止）

振る舞い検証の実装

振る舞い記述の検証レベル:

判定基準: 「観測可能な結果」がテスト対象の戻り値またはモックの呼び出し引数として検証されていれば合格

検証項目の決定ルール

// 検証項目:

// 検証項目:

統合テストのモック境界

判定フロー:

1. 外部API（HTTP通信）→ モック必須
2. テスト対象のコンポーネント間連携 → 実物必須
3. ログ出力の検証が必要 → 検証可能なモック（vi.fn()）を使用
4. ログ出力の検証が不要 → 実物または無視

E2Eテストの実行条件

• 全コンポーネント実装完了後に実行
• モック禁止（

  @dependency: full-system

  ）

レビュー基準

スケルトンと実装の整合性

実装品質