tdd

テスト駆動開発

TDD は red → green のループです。このスキルは、そのループから維持する価値のあるテストを生み出すためのリファレンスです。優れたテストとは何か、テストをどこに置くか、アンチパターン、ループのルールを扱います。すべてのセクションは毎サイクルに適用されます。ループの前と最中に参照し、後から参照するのではありません。

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

優れたテストとは

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

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

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

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

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

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

そのインターフェースの形そのもの（モジュールの深さ、シームの場所、インターフェースで公開すべき内容）が問題になっている場合は、用語を確認するために Skill ツールを「codebase-design」とともに呼び出してください。これは、モジュール、インターフェース、深さ、シーム、アダプター、レバレッジ、局所性に関する用語の共有ソースであり、実行するセッションではなく、参照するためのリファレンスです。

アンチパターン

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

ループのルール

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