tdd

テスト駆動開発

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

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

優れたテストとは

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

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

シーム — テストを置く場所

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

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

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

インターフェース自体の形式、つまりモジュールの深さ、シームの位置、インターフェースで公開すべきものが問題になる場合は、用語を確認するために /codebase-design スキルを使ってください。このスキルは、モジュール、インターフェース、深さ、シーム、アダプター、レバレッジ、ローカリティという用語の共通の参照元です。実行するセッションではなく、参照用の指針です。

アンチパターン

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

ループのルール

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