generate-tests

テスト生成スキル

コードを分析し、指定された対象に対する高品質なユニットテストを生成します。

テスト対象： $ARGUMENTS

品質基準

• テストケースを生成する前に、時間をかけてコードを十分に分析してください。
• 速度よりも品質を重視してください。関連するすべてのソースファイルとルールを注意深く読んでください。
• 以下のワークフローの手順を省略しないでください。各手順には理由があります。
• テストデータで手を抜かないでください。実際のクラスを読み、正しいコンストラクターとフィールドを使用してください。

---

手順

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

1. コードの種類に基づいて、./rules/tests/ にある関連ルールを読む（「ルールの参照」を参照）
2. 対象のソースファイル／クラス／メソッドを読む
3. 依存関係を読む：対象が参照する DTO、エンティティ、列挙型、カスタム例外、その他の型を読み込むため、インポートをたどる（code-context-analysis ルールで指定されているとおり）
4. 既存のテストを確認する：テストディレクトリ内で {ClassName}Test または {ClassName}Tests を検索する（existing-test-awareness ルールで指定されているとおり）
   • 見つかった場合は、すべて読んでください。新しいファイルを作成するのではなく、不足しているテストを追加します
   • 見つからない場合は、プロジェクトの規約を把握するため、近くにあるテストクラスを 2～3 個調べてください

手順 2：テストケースの一覧を作成する

この対象のテストケース一覧がすでにある場合 — ユーザーまたはエージェントのどちらが実行したかにかかわらず、generate-test-cases が先に実行されています。その一覧を計画として使用し、そこからテストを生成してください。対象コードを最初から分析し直してはいけません。コードを読んだ結果、一覧と異なる場合は、追加または削除するケースとその理由を明記し、計画の変更が分かるようにしてください。

そのような一覧がない場合は、テストコードを書く前に、ここで作成してください。

1. 以下を含む、コード内のすべての分岐を分析します。
   • 成功パス
   • エラー／例外パス
   • バリデーションロジック
   • 対象から呼び出される private／protected メソッド
   • セキュリティアノテーション（存在する場合）
2. INCLUDE／EXCLUDE ルールを厳密に適用します
3. 以下の形式で一覧を出力します

どちらの場合も、続けて手順 3 に進んでください。一覧は、生成されたテストと計画をユーザーが後から照合できるように表示します。最初から最後まで、実行は無人で続行されます。

テストケースの出力形式

## 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

手順 3：テストコードを生成する

1. コードの種類を判定し、該当するルールを適用します。
   • コントローラー → controller-test-rules.md を適用（@WebMvcTest と MockMvc のパターンを使用）
   • サービス／ドメインロジック → domain-service-rules.md を適用（@ExtendWith(MockitoExtension.class) と Mockito のパターンを使用）
   • リポジトリ／メッセージング／その他の型 → 基本ルールとして domain-service-rules.md を適用します。型固有のルールはまだないことをユーザーに伝えてください
   • すべての Java コード → コードの種類にかかわらず、常に java-test-template.md、argument-matching.md、json-serialization.md を適用します
2. 手順 1 で既存のテストクラスが見つかった場合は、新しいテストメソッドを追加します（重複するファイルは作成しないでください）
3. すべてのルールと手順 2 のテストケースに従ってテストを生成します
4. Write ツールを使用してテストファイルを作成または更新します

手順 4：コンパイルと実行を検証する

1. コンパイルを実行し、問題を修正します（最大 5 回。compilation-verification.md を参照）
2. 生成したテストクラスを実行し、すべてのテストがパスすることを検証します（test-execution-verification.md を参照）
3. テストが失敗した場合は、テストを変更して修正します。本番コードはそのままにします
4. 3 回試しても修正できないテストはファイルに残し、理由を添えて @Disabled にし、その旨を報告します（test-execution-verification.md を参照）

---

トラブルシューティング

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

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

サポートされていない言語

対象のコードが個別のルールが定められていない言語（Java 以外）の場合は、一般ルールのみを適用し、言語固有の慣習については手作業で確認が必要になる可能性があることをユーザーに伝えてください。

コンパイルが繰り返し失敗する場合

5 回試行してもコンパイルに失敗する場合：

1. 中止し、残っているエラーをユーザーに示します
2. 考えられる原因（依存関係の不足、互換性のないバージョン）を提案します
3. 続行する前に、ビルドの問題を解決するようユーザーに依頼します

本番コードの動作が原因でテストが失敗する場合

本番コードの動作が想定と異なるためにテストが失敗する場合：

1. 本番コードは変更しないでください
2. 実際の動作に合わせてテストを修正します
3. 動作にバグがあると思われる場合は、コメントを追加します：// NOTE: current behavior may be a bug — {description}

---

例

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

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

Step 2: Agent outputs 7 test cases covering:
        - createOrder success path
        - createOrder with invalid request (validation)
        - processPayment success
        - processPayment failure
        - calculateTotal with products
        - calculateTotal with empty list
        - cancelOrder for non-existent order

Step 3: Agent generates OrderServiceTest.java with @ExtendWith(MockitoExtension.class),
        mocked repository and payment service, 7 test methods.

Step 4: Agent runs `mvn test -Dtest=OrderServiceTest -q`, all tests pass.

Result: Complete test file delivered with 7 passing tests.

---

ルールの参照

重要：./rules/tests/ ディレクトリにある、関連するすべてのルールを必ず読み、適用してください。

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

一般ルール（常に適用）

• general/test-case-generation-strategy.md - 対象に含める／除外する基準
• general/naming-conventions.md - テストの命名形式
• general/general-principles.md - テストの基本原則（Given-When-Then、実際値／期待値）
• general/technology-stack-detection.md - 言語とフレームワークの検出
• general/what-makes-good-test.md - 明確さ、完全性、簡潔さ、堅牢性
• general/cleanly-create-test-data.md - テストデータにはヘルパーとビルダーを使用
• general/keep-cause-effect-clear.md - 原因の直後に結果を記述
• general/no-logic-in-tests.md - DRY より KISS を優先し、アサーション内のロジックを避ける
• general/keep-tests-focused.md - 1 つのテストにつき 1 つのシナリオ
• general/test-behaviors-not-methods.md - 動作ごとにテストを分ける
• general/verify-relevant-arguments-only.md - 関連するモック引数のみを検証
• general/prefer-public-apis.md - private メソッドより public API をテスト
• general/existing-test-awareness.md - 既存のテストを確認し、プロジェクトの慣習に合わせる
• general/code-context-analysis.md - テストを作成する前に依存関係を読む

Java のユニットテスト

• java/unit/java-test-template.md - 基本テンプレート、使用禁止のアノテーション
• java/unit/json-serialization.md - 明示的な JSON リテラルを使用
• java/unit/argument-matching.md - any() ではなく ArgumentCaptor を使用
• java/unit/logging-rules.md - ログには OutputCaptureExtension を使用
• java/unit/domain-service-rules.md - サービス向けの Mockito パターン
• java/unit/controller-test-rules.md - コントローラー向けの @WebMvcTest と MockMvc のパターン

生成後

• post-generation/compilation-verification.md - コンパイルを検証
• post-generation/test-execution-verification.md - テストの成功を検証