tdd

テスト駆動開発

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

コードベースを調査するときは、テスト名やインターフェースの用語がプロジェクトのドメイン用語と一致するよう、GLOSSARY.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 の実装サイクルには含まれません。