test-suite-builder

テストスイートビルダー

ソースマッピング：Kotlin_Spring_Developer_Pipeline.md（SK-14）を基にした Tier 1 の重要スキルです。

ミッション

動作を証明できる、最も軽量なテストを選びます。 実装を一行ずつ再現するのではなく、リグレッションを検出できるテストを生成します。

テスト戦略から始める

コードを書く前に、何を証明する必要があるかを分類します。

• 純粋なビジネスロジック
• HTTP コントラクトとバリデーション
• リポジトリのクエリ動作
• シリアライズ動作
• セキュリティルール
• コンポーネント間の統合
• データベースまたはメッセージブローカーとの統合

3 層テスト戦略

• ドメインロジック、計算、判断テーブル、決定論的な分岐にはユニットテストを使用します。
• フレームワークとの境界にはスライステストを使用します。
  • HTTP には @WebMvcTest または WebTestClient
  • リポジトリには @DataJpaTest
  • プロジェクトで利用可能な場合は、対象を絞った JSON またはセキュリティのスライステスト
• 現実的なアプリケーション構成またはインフラストラクチャとの境界を証明する必要がある場合に限り、@SpringBootTest と Testcontainers を使用します。

Kotlin のテストルール

• JUnit 5 を優先します。
• リポジトリですでに別の方式が標準化されていない限り、Mockito より MockK を優先します。
• プロジェクトのスタイルに合う場合は、読みやすいバッククォート付きのテスト名を使用します。
• コルーチンを多用するコードには runTest とコルーチンテストツールキットを使用します。
• インラインでのオブジェクト構築を重複させるのではなく、再利用可能なフィクスチャー、ビルダー、またはオブジェクトマザーを作成します。

テスト対象

• 成功パス。
• バリデーションエラー。
• ビジネスルール違反。
• null 許容性、オプションフィールド、空のコレクション、重複に関するエッジケース。
• 作業のきっかけとなったバグや変更を対象とする、少なくとも 1 つのリグレッションテスト。

避けるべきこと

• スライステストやユニットテストで十分な場合に、安易に @SpringBootTest を使わないでください。
• モックとのやり取りだけを検証し、観測可能な動作を何も証明しないテストを書かないでください。
• 公開された動作で十分な場合に、アサーションを非公開の実装詳細に依存させないでください。
• 制御せずに実時間やランダム値を使ったり、変更可能な状態を共有したりしないでください。

出力形式

次のセクションを返します。

• Test plan：使用するテスト層とその理由。
• Generated tests：具体的なテストクラスまたはパッチ計画。
• Test data support：追加するビルダー、フィクスチャー、ファクトリー。
• Coverage gaps：まだカバーされていない重要なケース。
• Verification：実行するコマンドと、修正前に失敗するべきテスト。

フレームワーク固有の確認事項

• MVC と WebFlux に応じて、MockMvc と WebTestClient を使い分けます。
• リポジトリで実際に使用しているデータベースまたはブローカーに合わせて、Testcontainers を設定します。
• バグがシリアライズまたはバリデーションに関するものなら、サービスロジックだけでなく、通信時のコントラクトを証明するテストを含めます。
• トランザクション動作が重要な場合は、実際の永続化レイヤーでロールバックまたは一意性の動作を証明するテストを追加します。

高度なテスト上の注意点

• 常にロールバックするトランザクションテストでは、コミット時の失敗が隠れることがあります。一意制約、トリガー、トランザクションリスナーが重要な場合は、明示的なフラッシュまたは実際のコミット境界を使用します。
• 方言、JSON、ロック、インデックスの使用、トランザクションの意味論が重要な場合、H2 は Postgres や MySQL の安全な代替にはなりません。そのようなケースでは、Testcontainers で実際のエンジンを使用することを優先します。
• @MockBean は強力ですが、コストがかかります。多用すると、隠れた配線を持つ遅いユニットテストへと統合テストが変わってしまいます。
• セキュリティテストでは通常、認可された正常なパスだけでなく、401 と 403 の両方を検証します。
• 非同期処理やイベント駆動のフローには、制御されたスケジューラー、ラッチ、Awaitility など、決定論的な待機方法が必要です。あちこちに sleep を散在させないでください。
• 並行処理やデッドロックの動作は、単一スレッドのロールバックテストでは証明できません。こうしたケースを検証する場合は、複数のトランザクションと明示的な同期を使用します。
• コンテナの再利用は速度向上につながりますが、厳密な状態分離が必要です。ビルドを高速化するために決定性を犠牲にしないでください。
• ビジネスロジックが時計や UUID に依存する場合は、決定論的な時刻プロバイダーと ID プロバイダーを使用します。

エキスパートのヒューリスティクス

• バグの原因がフレームワークの配線にある場合は、ユニットテストより上位レベルのテストを少なくとも1つ追加します。
• バグの原因がドメインの分岐にある場合は、修正のために Spring コンテキスト全体を持ち込まないでください。
• 迷ったときは、変更前に失敗する最小のテストを選びます。
• テストコードも本番コードと同様に、読みやすさと保守性を重視します。フィクスチャやヘルパーはノイズを減らすために使い、動作を隠さないようにします。

ガードレール

• テストの決定性を保ちます。
• セットアップは明示的にし、シナリオごとに局所化します。
• 1つのテストにつき、失敗理由は明確に1つにすることを優先します。
• 高速なユニットテストスイートに、遅くインフラへの依存が大きいテストを密かに追加しないでください。

品質基準

このスキルを適切に実行すると、可能な限り高速で、必要な箇所では現実的なテストスイートができます。 適切に実行できていない場合は、コンテキストへの依存が大きいテストや壊れやすいモックがプロジェクトにあふれ、各テストレベルを設ける理由も明確に説明されません。