tdd

テスト駆動開発

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

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

優れたテストとは

テストでは実装の詳細ではなく、パブリックインターフェースを通じて振る舞いを検証します。コードは全面的に変更されてもかまいませんが、テストは変えるべきではありません。優れたテストは仕様のように読めます。「ユーザーは有効なカートで購入手続きを完了できる」とあれば、どのような機能があるかが正確に分かります。また、内部構造に依存しないため、リファクタリング後も機能します。

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

シーム — テストを行う場所

シームとは、テスト対象となるパブリックな境界、つまり内部に立ち入らずに振る舞いを観察するインターフェースです。テストはシームに対して行い、内部に対して行うことはありません。

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

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

インターフェースの形自体が問題になっている場合、つまりモジュールの深さ、シームの位置、インターフェースが公開すべき内容について検討する場合は、用語を確認するために /codebase-design スキルを使ってください。これはモジュール、インターフェース、深さ、シーム、アダプター、レバレッジ、局所性に関する用語の共通の情報源であり、実行するセッションではなく、参照する資料です。

アンチパターン

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

ループのルール

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