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

テスト種別と上限

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

振る舞い優先の原則

観測可能性チェック（全て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
it.todo('[AC番号]: [テスト名]')

Property注釈

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

ROI計算

ROI = (ビジネス価値 × 頻度 + 法的要件 × 10 + 欠陥検出) / 総コスト

実装ルール

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）

レビュー基準

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

実装品質