tdd

テスト駆動開発

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

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

優れたテストとは

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

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

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

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

シームはすでに合意されている場合があります。次のうち、最初に存在するものを参照してください。

1. チケットの Seams: 行（またはリモートチケットの Seams セクション）。
2. 仕様書の Testing Decisions。
3. いずれもない。

情報源に記載されたシームは確認済みとみなされます。質問せずに、そのシームに対するテストを書いてください。リストにないシームについてのみユーザーに確認し、合意したらリストに追加してください。

情報源がない場合（チケットや仕様書のない単独での使用）は、テスト対象のシームを書き出し、テストを書く前にユーザーに確認してください。「公開インターフェースは何ですか。また、どのシームをテストしますか？」と尋ねます。提案する各シームについて、何を検出し、何を検出できないかを一行で説明してください。

そのインターフェースの形自体が未確定の場合、つまりモジュールの深さ、シームの位置、インターフェースが公開すべき内容が問題となっている場合は、まずそれを解決してからシームに合意してください。

アンチパターン

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

ループのルール

• green の前に red。 まず失敗するテストを書き、それを通すのに必要な最小限のコードだけを書きます。将来のテストを先回りしたり、推測に基づく機能を追加したりしないでください。
• 一度に1つのスライス。 1サイクルにつき、シーム1つ、テスト1つ、最小限の実装1つです。
• リファクタリングはループに含めません。 これは implement スキルの Refactor ステップで行い、red → green の実装サイクルでは行いません。