[Skill 名] java-unit-test

Java単体テストスキル

トリガー条件

ユーザーが以下の要求（同義表現を含む）を提示した場合に、このスキルをアクティブ化します。

• 単体テストを書いてください / このクラスのテストを書いてください / テストケースを生成してください
• テストカバレッジを向上させてください / テストを補完してください / カバレッジが基準を満たしていません
• junit test / mockito test / unit test

事前チェックリスト

テストコードを生成する前に、以下のチェックと情報収集を完了する必要があります（不足している場合は、まず補完してください）。

1) テスト対象クラス（SUT）の特定

• テスト対象クラスのソースファイルとその直接的な依存関係（コンストラクタパラメータ、フィールドインジェクション、静的依存関係）を読み取ります。
• パッケージ名、クラス名、可視性、コンストラクタ、すべての public メソッドシグネチャを記録します。

2) クラス構造と動作の分析

• public メソッドを一つずつ整理します。
  • 入力パラメータ、戻り値、スローされる例外
  • 分岐条件と境界値（null/空のコレクション/0/負数/超長文字列など）
  • 外部との相互作用：データベース/キャッシュ/HTTP/RPC/ファイル/時間/乱数など

3) 依存関係と Mock 可能な点の特定

• 置換可能な依存関係（インターフェース/コンポーネント/DAO/Client）を特定し、Mock/Spy の対象を明確にします。
• Mock できない、または Mock が難しい点（static/final/private/new で生成されるオブジェクト）をマークします。

4) テストプロジェクトとフレームワークの制約の確認

• プロジェクトで使用されているテストフレームワークとバージョン（JUnit 4/5、Mockito、Spring Testなど）を確認します。
• テストソースのディレクトリ構造（例：src/test/java とパッケージパスが一致しているか）を確認します。
• アサーションライブラリとスタイル（JUnit Assertions / AssertJ / Hamcrest など、プロジェクトの現状に優先して従います）を確認します。

テストコード生成の規範

1) テストクラス命名規範

• テストクラス名：{テスト対象クラス名}Test
• 複数の実装または複数のシナリオに分割されている場合：{テスト対象クラス名}{シナリオ}Test（例：OrderServiceCreateTest）

2) Import 宣言規範

• 以下の順序で import を整理します。
  1. java.*
  2. javax.*
  3. サードパーティライブラリ（org. / com.）
  4. プロジェクト内部パッケージ
  5. static import（アサーション、Mockito 静的メソッド）
• 未使用の import は禁止です。

3) テストクラス構造テンプレート

• 統一された構造：
  • Mock 宣言領域
  • テスト対象オブジェクト構築領域（例：@InjectMocks または手動での new）
  • 共通テストデータ構築メソッド（オプション）
  • ユースケース領域：テスト対象メソッドごとにグループ化

推奨される骨格（プロジェクトフレームワークに応じていずれかを選択）：

1. 純粋な Mockito（優先）：

   • @ExtendWith(MockitoExtension.class)
   • @Mock 依存関係
   • @InjectMocks テスト対象オブジェクト（またはコンストラクタインジェクションによる手動 new）

2. Spring が関与する場合（プロジェクトにこのスタイルが既にあり、かつ必要不可欠な場合のみ）：

   • @SpringBootTest / @ExtendWith(SpringExtension.class)
   • @MockBean で外部依存関係を置き換え

4) Mock オブジェクト設定規範

• Mock の動作は「最小限の必要性」の原則に従います。現在のユースケースに必要な呼び出しのみをスタブします。
• 外部依存関係との相互作用は検証（verify）する必要があります。
  • 呼び出されたかどうか
  • 呼び出し回数（times / never）
  • 重要な入力パラメータ（ArgumentCaptor または eq）
• 実装の詳細を過度に検証しないでください（脆弱なテストを避けるため）。

5) テストデータ構築規範

• プロジェクトに既存の Builder/Factory メソッドがある場合は、それらを使用してテストデータを構築することを優先します。
• Builder がない場合は、専用のプライベートメソッドを使用して一般的なオブジェクトを構築します。
  • buildValidXxx()
  • buildXxxWithBoundary()
• 単一のテストメソッド内で大量のオブジェクト構築ロジックを積み重ねることを避けます。

6) アサーション規範

• 各テストは、そのシナリオの主要な出力と主要な副作用のみをアサートします。
• アサーションの優先順位：
  • ビジネスの戻り値/状態
  • 外部依存関係との相互作用（verify）
  • 生成された永続化/イベント（もしあれば）

7) 例外と境界ユースケース規範

• 不正なパラメータ、依存関係の例外、null/空のコレクションを返すシナリオは必ずカバーする必要があります。
• 例外アサーションには assertThrows を使用し、例外メッセージまたはエラーコード（安定している場合）を検証します。

8) パラメータ化テスト（オプション）

• 複数の同等な入力の組み合わせがあり、アサーションが同じである場合は、パラメータ化テストを優先します。
• プロジェクトが JUnit 5 のパラメータ化サポートを既に利用している場合にのみ有効にします。

テストケース設計原則

1) カバレッジ戦略

• public メソッドの以下をカバーします。
  • 正常なフロー（Happy Path）
  • 主要な分岐（if/else、switch、early return）
  • 境界条件（境界値、null値、極端な値）
  • 例外フロー（依存関係のエラー、ビジネス検証の失敗）

2) テストピラミッド

• 単体テストは純粋なビジネスロジックと境界条件を優先してカバーします。
• 結合テストは主要な経路と契約のみをカバーします（このスキルは単体テストに重点を置いています）。

3) カバレッジ目標（チームの要求に応じて調整）

• 保守性を優先し、主要なロジックと高リスクモジュールをカバーします。
• 「薄いラッパー/純粋な転送」コードに対しては、カバレッジを過度に追求しません。

ベストプラクティスチェックリスト

命名チェックリスト

• テストメソッド名には、メソッド名 + シナリオ + 期待される結果を含めます。
• 命名スタイルを統一します（いずれかを選択し、一貫性を保ちます）。
  • shouldXxxWhenYyy
  • givenYyyWhenXxxThenZzz

構造チェックリスト

• Arrange / Act / Assert の三段構成を明確にします。
• 単体テストは実行順序に依存せず、繰り返し実行可能です。
• 単体テストは実際の時間/乱数に依存しません（必要に応じて Clock/Random を注入するか、ラップします）。

アサーションチェックリスト

• アサーションはできるだけ具体的にし、「只 assertNotNull」のような弱いアサーションは避けます。
• コレクション/オブジェクトのアサーションでは、主要なフィールドに注目し、全量オブジェクトのアサートによる脆弱性を避けます。

Mock チェックリスト

• deep stubs は避けます。
• プライベートメソッドのテストは避けます（外部から観測可能な動作をテストします）。

パフォーマンスチェックリスト

• 単体テストは高速であるべきです（通常ミリ秒単位）。
• スレッドスリープ、実際の IO、ネットワークリクエストは避けます。

よくある質問と解決策

1) 静的メソッドの Mock が難しい

• 優先的にリファクタリングします。注入可能な依存関係で静的呼び出しをラップします。
• プロジェクトが Mockito inline などの機能を既に有効にしている場合にのみ、静的 Mock を検討します（慎重に使用してください）。

2) final クラス/メソッドの Mock の問題

• 優先的にプロジェクトの既存の Mockito 設定に従います。必要に応じて Mockito inline を使用します。

3) プライベートメソッドをどのようにテストするか

• プライベートメソッドを直接テストしません。public メソッドの入出力と副作用を通じてそのロジックをカバーします。