tdd

テスト駆動開発

TDD は red -> green のループです。このスキルは、そのループで残す価値のあるテストを作成するためのリファレンスです。優れたテストとは何か、テストをどこに配置すべきか、アンチパターン、ループのルールを説明します。後からではなく、各サイクルの前とサイクル中に参照してください。

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

優れたテストとは

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

例は tests.md を、モックのルールは mocking.md を参照してください。

シーム：テストを配置する場所

シームとは、テスト対象となるパブリックな境界です。内部に踏み込まずに振る舞いを観察できるインターフェースを指します。テストはシームに対して行い、内部を対象にしてはいけません。

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

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

インターフェースの形そのものが問題である場合（モジュールをどの程度深くすべきか、シームをどこに置くべきか、インターフェースで何を公開すべきか）は、Skill ツールを呼び出し、codebase-design を指定して用語を確認してください。これはモジュール、インターフェース、深さ、シーム、アダプター、レバレッジ、ローカリティに関する用語の共通の参照元です。実行するセッションではなく、参照用のリファレンスです。

アンチパターン

• 実装との結合：内部の協力オブジェクトをモックする、プライベートメソッドをテストする、またはサイドチャネルを通じて検証する（たとえば、インターフェースを使わずにデータベースへ直接問い合わせる）。振る舞いは変わっていないのに、リファクタリングでテストが失敗するのが特徴です。
• 同語反復的なテスト：アサーションで、コードと同じ方法により期待値を再計算する（expect(add(a, b)).toBe(a + b)、同じロジックで手作業でスナップショットを生成する、定数が自身と等しいことをアサートするなど）ため、必ずパスし、コードと食い違うことがありません。期待値は、既知の正しいリテラル、具体例、仕様など、独立した真実のソースから取得してください。
• 水平スライス：先にすべてのテストを書き、その後ですべての実装を行うこと。一括で書かれたテストが検証するのは、想像上の 振る舞いです。ユーザーに見える振る舞いではなく、ものの 形 をテストしているため、実際の変更に鈍感になり、実装を理解する前にテスト構成を確定してしまいます。代わりに 垂直スライスを使います。1 つのテスト -> 1 つの実装 -> 繰り返し、各テストは前の学びに応じた トレーサーバレットとなります。

ループのルール

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