generate-test-cases

テストケース生成スキル

コードを分析し、指定されたメソッド／クラスに対して作成すべきテストケースの一覧を生成します。このスキルが出力するのはテストケースの説明のみであり、実際のテストコードは生成しません。

分析対象： $ARGUMENTS

品質基準

• テストケースを列挙する前に、時間をかけてコードを徹底的に分析してください。
• 速度より品質を重視してください。関連するすべてのソースファイルとルールを注意深く読んでください。
• 依存クラスの読み込みを省略しないでください。全体のコンテキストを理解することで、より良いテストケースを作成できます。

---

指示

ステップ 1：ルールを読み、コンテキストを分析する

1. ./rules/general/ ディレクトリからルールを読みます（「ルールの参照」を参照）
2. 上記で指定された対象のソースファイル／クラス／メソッドを読みます
3. 依存関係を読む：対象からインポートされている DTO、エンティティ、列挙型、その他の型をたどって読みます（code-context-analysis ルールの指定に従います）
4. 既存のテストを確認する：対象をカバーする既存のテストクラスを検索します（existing-test-awareness ルールの指定に従います）。見つかった場合は最後まで読み、まだカバーされていない動作だけに焦点を当てます

ステップ 2：テストケースを生成する

1. 以下を含む、すべてのコード分岐を分析します。
   • 成功パス
   • エラー／例外パス
   • バリデーションロジック
   • 対象から呼び出されるプライベート／プロテクトメソッド
   • セキュリティアノテーション（存在する場合）
2. INCLUDE／EXCLUDE ルールを厳密に適用します
3. 指定された形式でテストケースの一覧を出力します
4. 説明の出力までで終了します。一覧自体がこのスキルの成果物です
5. 次のステップを明記して締めくくります。generate-tests <target> は、この一覧を計画として使い、そこからコードを作成します。一覧はそのまま引き継いでください。ユーザーは事前に確認したり、修正したりできます

---

出力形式

テストケースごとに、以下を記述します。

## Test Cases for {ClassName}.{methodName}

### 1. {testMethodName}
- **Given:** {preconditions/input state}
- **When:** {action being tested}
- **Then:** {expected outcome}
- **Code branch:** {which code path this covers}

### 2. {testMethodName}
...

命名規則

テストメソッド名の形式：{testedMethod}_{givenState}_{expectedOutcome}

例：

• calculateTotal_validProducts_returnsSum
• calculateTotal_emptyList_throwsIllegalArgumentException
• getUser_unauthorized_returns401
• getUser_forbidden_returns403

---

トラブルシューティング

対象ファイルが見つからない

指定された対象が存在しない場合は、検索した正確なパスをユーザーに伝え、詳細を確認してください。

サポート対象外の言語

対象コードが個別のルールのない言語で書かれている場合は、一般ルールのみを適用し、その旨をユーザーに伝えてください。

すべての動作がすでにカバーされている

既存のテストクラスが特定されたすべての動作をすでにカバーしている場合は、カバレッジが完全であることを要約して出力します。すでにテストされている項目を列挙してください。分析の正当化のために、追加のテストケースをでっち上げてはいけません。

---

例

User says: "/generate-test-cases src/main/java/com/example/service/OrderService.java"

Step 1: Agent reads rules, reads OrderService.java, reads OrderRequest.java,
        Order.java (dependencies), checks for existing OrderServiceTest.java.

Step 2: Agent outputs:

## Test Cases for OrderService.createOrder

### 1. createOrder_validRequest_savesAndReturnsOrder
- **Given:** Valid OrderRequest with productId "product-1" and quantity 5
- **When:** createOrder is called
- **Then:** Order is saved to repository and returned with generated ID
- **Code branch:** Success path

### 2. createOrder_nullProductId_throwsIllegalArgumentException
- **Given:** OrderRequest with null productId
- **When:** createOrder is called
- **Then:** IllegalArgumentException is thrown
- **Code branch:** Validation — productId null check
...

---

ルールの参照

重要：テストケースを生成する前に、以下のファイルにあるすべてのルールを必ず読み、適用してください。

メンテナンスに関する注意： ./rules/general/ の一般ルールは、generate-tests スキルと共有されています（rules/tests/general/ にコピーがあります）。ルールを更新するときは、両方の場所を同期してください。

全般的なルール（常に適用）

• ./rules/general/test-case-generation-strategy.md - テストケースの採用／除外基準
• ./rules/general/naming-conventions.md - テストの命名形式
• ./rules/general/general-principles.md - テストの基本原則
• ./rules/general/what-makes-good-test.md - 明確さ、完全性、簡潔さ、堅牢性
• ./rules/general/keep-tests-focused.md - 1つのテストにつき1つのシナリオ
• ./rules/general/test-behaviors-not-methods.md - 振る舞いごとにテストを分ける
• ./rules/general/prefer-public-apis.md - プライベートメソッドではなくパブリック API をテストする
• ./rules/general/cleanly-create-test-data.md - テストデータにはヘルパーやビルダーを使用する
• ./rules/general/keep-cause-effect-clear.md - 原因の直後に結果を記述する
• ./rules/general/no-logic-in-tests.md - KISS > DRY、アサーションにロジックを含めない
• ./rules/general/technology-stack-detection.md - 言語とフレームワークを検出する
• ./rules/general/verify-relevant-arguments-only.md - 関連するモック引数のみを検証する
• ./rules/general/existing-test-awareness.md - 既存のテストを確認し、重複を避ける
• ./rules/general/code-context-analysis.md - 分析の前に依存関係を読む