Skill.md検索

Red → Green の厳密な順序を守り、失敗するテストが先にあることで「テストが本当にバグを検知できる」ことを証明してから実装できます 既存テストの規約（モック・フィクスチャ・命名・アサーション）を自動で分析し、プロジェクトのお作法に沿ったテストコードを書けます シグネチャ変更時に呼び出し元の既存テストをすべて更新し、テストスイート全体の整合性を保ったまま実装できます エッジケース（空入力・エラーパス・境界値）をテスト段階で網羅し、リグレッションを未然に防げます テスト実行結果を厳密に確認し、「パスしてしまう無意味なテスト」を防止できます テスト駆動開発で品質を重視する開発者 既存コードを改修するとき、リグレッション（既存機能の破壊）を確実に防ぎたい人 「テストを書いたはずなのに、バグを検知できなかった」という経験から脱却したい人 チームでテストコードの品質・一貫性を高めたい人 TDD の核心は Red → Green の順序厳守で、逆は許されません。Step 0 では既存テストファイル 1-2 本を読み、モック（unittest.mock/pytest-mock/MagicMock/AsyncMock）・フィクスチャ（pytest フィクスチャ vs. ヘルパー関数）・命名（test__）・アサーション・import パス・ファイル配置を確認し踏襲します。Step 1（Red）では実装前にすべてのテストを書き、振る舞いテスト・エッジケース網羅・1 テスト 1 アサーション・具体的な名前を意識し、シグネチャ変更時は呼び出し元テストもすべて更新します。実装なしでハードコード値を返すスタブすら書きません。Step 2 では pytest/npm test/go test など対象ツールでテストを実行し、ImportError/TypeError/AssertionError などの Red 状態を確認し、新テストが無意味にパスしないことを検証します。Red 確認なしに Step 3 に進んではいけません。Step 3（Green）では最小限の実装でテストをパスさせ、テストが要求しないシナリオのエラーハンドリング・将来要件の抽象化・過剰機能は追加しません。Step 4 で全テストスイートをパスさせ、リグレッション修正で完了、Step 5 でユーザーにテスト本数・変更内容・判断を報告します。

テスト構造の標準化：@Nested inner classで「前提条件」と「期待する振る舞い」を明確に分離し、テストコードの可読性と保守性を大幅に向上させられます。 テスト失敗原因の即座の把握：アサーションをテスト本体に集約することで、テストが失敗した理由と文脈がひと目でわかり、デバッグ時間を短縮できます。 ヘルパー関数の責務明確化：セットアップと操作実行に専念させ、アサーション判定を含めないルールで、関数の役割が明確になり再利用性が高まります。 null安全なテスト記述：assertNotNullで事前チェックしてから値を扱うことで、NullPointerExceptionではなく「値がnullだった」という明確なエラーメッセージを得られます。 セットアップの効率的な集約：@BeforeEachやwrapper関数を使い、コンテキスト内の重複セットアップを一箇所に集約できます。 Kotlinエンジニア：JUnit5を使ったテストコードを新規作成・レビュー・リファクタリングする際に一貫したパターンを適用したい。 QAエンジニア：テストの構造改善と失敗時の原因特定を迅速に行いたい。 新人・ジュニアエンジニア：テストコードの「良い書き方」を体系的に学びたい。 チームリード：チーム全体のテストコード品質を統一し、レビュー基準を明確にしたい。 このスキルは、Koyプロジェクト（Kotlin・JUnit5・Gradle）におけるテスト書き方の標準パターン集です。1. context/test構造では、@Nested inner classを使用し、クラス名に「when ...」で前提条件を表現し、テスト名に「should ...」で期待する振る舞いを表現。2. ユーティリティとアサーションの分離では、ヘルパー関数はセットアップと操作実行のみの責務とし、アサーションを含めない。これによってテスト失敗時の理由が明確になります。3. nullチェックの順序では、nullable値を使用前にassertNotNullで存在確認してから内容をアサート。4. セットアップの集約では、@BeforeEachで共通セットアップを集約、Ktor固有のtestApplicationはwrapper関数で集約する方法を規定しています。