tdd

テスト駆動開発

TDD は、赤 → 緑のループです。このスキルは、そのループで長く使えるテストを作るための指針です。優れたテストとは何か、テストをどこに配置するか、アンチパターン、ループのルールを説明します。すべてのセクションは毎サイクルに適用されます。ループの後ではなく、ループの前と最中に参照してください。

コードベースを調査するときは、テスト名やインターフェースの用語がプロジェクトのドメイン用語と一致するよう、GLOSSARY.md（存在する場合）を読み、作業対象の領域に関する ADR に従ってください。

優れたテストとは

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

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

シーム：テストする場所

シームとは、テスト対象となる公開境界です。内部に立ち入らずに振る舞いを観察するインターフェースを指します。テストはシームに配置し、内部実装を対象にしてはいけません。

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

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

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

アンチパターン

• 実装との結合：内部の協調者をモックしたり、プライベートメソッドをテストしたり、サイドチャネルを介して検証したりします（インターフェースを使わずにデータベースを照会するなど）。見分けるポイントは、振る舞いが変わっていないのにリファクタリングでテストが壊れることです。
• 同語反復的：アサーションで、コードと同じ方法で期待値を再計算します（expect(add(a, b)).toBe(a + b)、手作業で同じ方法により作成したスナップショット、自分自身と等しいと検証される定数など）。そのため、テストは必然的に成功し、コードと食い違うことがありません。期待値は、既知の正しいリテラル、計算例、仕様など、独立した信頼できる情報源から得る必要があります。
• 水平スライス：先にすべてのテストを書き、その後に実装をすべて行います。テストをまとめて書くと、_想像上の_振る舞いを検証することになります。ユーザーに見える振る舞いではなく、ものの_形_をテストし、実際の変更に対してテストの感度が低くなり、実装を理解する前にテスト構造を確定させてしまいます。代わりに、垂直スライスで進めてください。1 つのテスト → 1 つの実装を繰り返し、各テストをトレーサーバレットとして、直前のサイクルで得た学びに応じて進めます。

ループのルール

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