tdd

TDD — テスト駆動開発

テスト駆動開発です。ユーザーがテストファーストで機能を開発したり、バグを修正したりしたい場合、「レッド・グリーン・リファクタリング」に言及した場合、または統合テストを希望する場合に使用します。

このスキルは mattpocock/skills（MIT）からインポートされており、上流ではモデルによって呼び出されます。

このスキルを使う場面

• テスト駆動開発。
• ユーザーがテストファーストで機能を開発したり、バグを修正したりしたい場合、「レッド・グリーン・リファクタリング」に言及した場合、または統合テストを希望する場合に使用します。

手順

テスト駆動開発

TDD は、レッド → グリーンのループです。このスキルは、そのループで維持する価値のあるテストを作成するためのリファレンスです。優れたテストとは何か、テストをどこに配置するか、アンチパターン、そしてループのルールを説明します。すべてのセクションは各サイクルで適用されます。ループの後ではなく、ループの前と実行中に参照してください。

コードベースを調査するときは、テスト名やインターフェースの語彙がプロジェクトのドメイン用語と一致するように、CONTEXT.md（存在する場合）を読み、変更する領域の ADR を尊重してください。

優れたテストとは

テストでは、実装の詳細ではなく、公開インターフェースを通じて振る舞いを検証します。コードの内部は全面的に変更されてもかまいませんが、テストは変わるべきではありません。優れたテストは仕様書のように読めます。「ユーザーは有効なカートでチェックアウトできる」と書けば、どのような機能があるかが正確にわかり、内部構造を気にしないためリファクタリングにも耐えられます。

例については tests.md を、モックのガイドラインについては mocking.md を参照してください。

シーム：テストする場所

シームとは、内部に立ち入らずに振る舞いを観察するインターフェース、つまりテストする公開境界です。テストはシームに対して行い、内部に対しては決して行いません。

事前に合意したシームだけをテストしてください。 テストを書く前に、テスト対象のシームを書き出し、ユーザーに確認してください。確認されていないシームに対してテストを書いてはいけません。すべてをテストすることはできないため、あらかじめシームに合意することで、すべてのエッジケースではなく、重要な経路や複雑なロジックにテストの労力を集中できます。

次のように尋ねてください。「公開インターフェースは何ですか？ どのシームをテストすべきですか？」

インターフェースの形自体が問題となる場合（モジュールの深さ、シームの配置、インターフェースで公開すべき内容など）は、語彙を確認するために Skill ツールで「codebase-design」を呼び出してください。これは、モジュール、インターフェース、深さ、シーム、アダプター、レバレッジ、局所性に関する用語の共通の参照元です。実行するセッションではなく、参照するための資料です。

アンチパターン

• 実装に結合したテスト：内部の協力オブジェクトをモックする、プライベートメソッドをテストする、またはサイドチャネルを通じて検証する（インターフェースではなくデータベースを直接クエリするなど）。テストは、振る舞いが変わっていないのにリファクタリングで失敗します。
• トートロジー的なテスト：コードと同じ方法で期待値を再計算するアサーション（expect(add(a, b)).toBe(a + b)、手作業で同じ方法で導出したスナップショット、定数がそれ自身と等しいことの検証など）です。こうしたテストは必ず通り、コードとの食い違いが起きることもありません。期待値は、既知の正しいリテラル、具体的な計算例、仕様など、独立した正解の情報源から取得する必要があります。
• 水平スライス：すべてのテストを書いてから、すべての実装を書くことです。大量のテストは、_想像上の_振る舞いを検証します。ユーザー向けの振る舞いではなく、物事の_形_をテストし、実際の変更に反応しなくなり、実装を理解する前にテスト構造を決めてしまいます。代わりに垂直スライスで進めてください。つまり、テストを1つ書き、実装を1つ行うサイクルを繰り返します。各テストはトレーサーバレットとして、直前のサイクルで得た学びを反映します。

ループのルール

• グリーンの前にレッド。 まず失敗するテストを書き、次にそれを通すために必要なコードだけを書きます。将来のテストを先取りしたり、推測に基づく機能を追加したりしないでください。
• 一度に1つのスライス。 1つのシーム、1つのテスト、1つの最小限の実装を1サイクルで行います。
• リファクタリングはループに含まれません。 リファクタリングはレビュー段階で行います（code-review スキルを参照）。レッド → グリーンの実装サイクルには含めません。

例

• まず、このスキルを狭い範囲に適用し、出力が上記の形式に合っていることを確認してから、タスク全体に広げます。
• ステップでリポジトリや環境の情報が必要になったら、ユーザーに尋ねずに調べます。

ベストプラクティス

• 元の手順を維持します。逸脱する場合は、独自に判断して黙って進めず、明示的に記録します。
• このスキルでユーザー自身の判断として示されている箇所では、必ず作業を止めてユーザーに制御を戻します。
• 小さく元に戻せる変更を優先し、前提を隠さず明示します。

参考資料

• 元のスキル：mattpocock/skills skills/engineering/tdd/SKILL.md（コミット 3cca18b、MIT）
• 関連ドキュメント：references/mocking.md
• 関連ドキュメント：references/tests.md
• プロジェクト標準：.agent-skills/skill-standardization/SKILL.md
• 検証スクリプト：.agent-skills/skill-standardization/scripts/validate_skill.sh