test-scope-definitionlisted

## Purpose 「テストを書いたが重要な箇所が抜けていた」「テストが多すぎて保守できない」を防ぐ。 変更の種別とリスクに応じて、最小限かつ十分なテストスコープを定義する。 ## Use When - 実装・変更の前後にテスト方針を決めたい場合 - レビュー前にテストカバレッジを確認したい場合 - テストを書く優先度をつけたい場合 - 施工AIへのタスク委譲時にテスト要件を明示したい場合 ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **変更内容**: テスト対象となる実装・変更の説明 - **変更種別**: 新機能追加 / バグ修正 / リファクタリング / DB マイグレーション / API 変更 - **影響範囲**: 変更が波及する機能・API・DB テーブル - **既存テスト**: 現在のテストファイル・テスト種別・カバレッジ概要 - **テストツール**: 使用するテストフレームワーク・ツール ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: このテストスコープを左右する核心的な判断軸 2. **根拠**: その論点をそう判断した理由 3. **テストスコープ定義**: 種別・対象・優先度・合否基準の一覧 4. **含意**: このスコープの網羅度と残存リスクの意味 5. **改善案**: テストコストを下げつつカバレッジを上げる工夫 6. **代替案**: フルテストが困難な場合のリスクベース優先付け 7. **判断材料**: 「このスコープで進む / スコープを縮小する / スコープを拡大する」を選ぶための情報 ### テストスコープ定義 フォーマット | テスト種別 | 対象 | 優先度 | 合否基準 | |---|---|---|---| | ユニットテスト | （関数・モジュール名） | 必須 / 推奨 / 任意 | （どういう状態をパスとするか） | | 統合テスト | （エンドポイント・フロー名） | 必須 / 推奨 / 任意 | | | E2E テスト | （ユーザーシナリオ名） | 必須 / 推奨 / 任意 | | | 手動確認 | （確認手順名） | 必須 / 推奨 / 任意 | | | パフォーマンステスト | （対象処理名） | 必須 / 推奨 / 任意 | | テスト種別は実際に使用するもののみ記載すること。 ## Review Lens - **目的妥当性**: テストスコープが変更リスクに対して適切か - **範囲の過不足**: 重要なユーザーシナリオが抜けていないか / 過剰テストになっていないか - **中長期リスク**: テストが増えすぎて保守コストが上がらないか - **LAB全体との整合性**: 既存テスト構成（Vitest / Playwright 等）と整合しているか - **非エンジニア理解可能性**: 合否基準が非技術者に説明できるか - **他LLM移植耐性**: テスト種別の定義が Claude 固有の解釈に依存していないか ## Instructions 1. 変更種別に応じてテスト戦略の重点を変える（新機能→正常系、バグ修正→再現ケース、リファクタ→既存動作保証） 2. 変更の影響範囲を元にテスト対象を列挙する 3. 各テスト対象に優先度（必須 / 推奨 / 任意）を付ける 4. 「必須」のテストが全通過しない場合はマージ・デプロイ不可とする基準を