tdd

テスト駆動開発

TDD は red → green のループです。このスキルは、そのループで後々も残す価値のあるテストを作るための指針です。優れたテストとは何か、テストをどこに置くか、アンチパターン、ループのルールを説明します。各セクションはすべてのサイクルに適用されます。ループの後ではなく、ループの前と最中に参照してください。

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

優れたテストとは

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

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

テストを行う境界

シームとは、テスト対象とする公開境界のことです。内部に立ち入らずに動作を観察できるインターフェースです。テストはシームで実施し、内部実装を対象にしてはいけません。

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

「公開インターフェースは何ですか。どのシームをテストすべきですか」と尋ねてください。提案する各シームについて、何を検出し、何を検出しないのかを一行で説明してください。

インターフェース自体の形（モジュールの深さ、シームの位置、インターフェースが公開すべき内容）が検討事項である場合は、「codebase-design」スキル（SKILL.md を読む）を読み込んで用語を確認してください。モジュール、インターフェース、深さ、シーム、アダプター、レバレッジ、局所性に関する用語の共通の参照元であり、実行するセッションではなく、参照すべき資料です。

アンチパターン

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

ループのルール

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