tracer-tdd

テスト駆動開発

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

コードベースを調べる際は、CONTEXT.md（存在する場合）を読み、テスト名とインターフェースの用語がプロジェクトのドメイン言語に合うようにしてください。また、変更する領域の ADR に従ってください。

優れたテストとは

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

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

シーム — テストする場所

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

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

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

アンチパターン

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

ループのルール

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