tdd

テスト駆動開発

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

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

優れたテストとは

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

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

シーム — テストする場所

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

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

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

アンチパターン

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

ループのルール

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