unity-tdd

テスト駆動開発

TDD は、red → green のループです。このスキルは、そのループで維持する価値のあるテストを作るための指針です。優れたテストとは何か、テストをどこに置くか、アンチパターン、ループのルールを説明します。すべてのセクションは各サイクルに適用されます。ループの前と実行中に参照してください。後から読むものではありません。

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

優れたテストとは

テストでは、実装の詳細ではなく、パブリックインターフェースを通じて動作を検証します。コードは全面的に変更されることがありますが、テストは変わるべきではありません。優れたテストは仕様のように読めます。「プレイヤーは死亡後、最後のチェックポイントで復活する」は、どのような機能があるのかを正確に示しており、内部構造に依存しないため、リファクタリング後も維持できます。

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

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

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

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

「パブリックインターフェースは何ですか？ どのシームをテストすべきですか？」と尋ねてください。提案するシームごとに、何を検出し、何を検出しないのかを一行で記してください。

インターフェースの形状そのもの（モジュールの深さ、シームの配置、インターフェースで公開すべきもの）が検討事項である場合は、用語を確認するために Skill ツールで「codebase-design」を呼び出してください。これは、モジュール、インターフェース、深さ、シーム、アダプター、レバレッジ、局所性に関する用語の共通の参照元です。実行するセッションではなく、参照するための資料です。

アンチパターン

• 実装との結合：内部の協調要素をモックする、プライベートメソッドをテストする、またはサイドチャネルを通じて検証する（インターフェースを使わずにデータベースへ問い合わせるなど）。目安は、動作が変わっていないのにリファクタリングでテストが失敗することです。
• 同語反復的：コードと同じ方法で期待値を再計算するアサーション（expect(add(a, b)).toBe(a + b)、手作業で同じ方法を使って導出したスナップショット、自分自身と等しいと検証する定数など）を使うため、仕組み上必ず成功し、コードと食い違うことがありません。期待値は、既知の正しいリテラル、計算例、仕様など、独立した真実の情報源に基づく必要があります。
• 水平分割：すべてのテストを書いてから、すべての実装を書くことです。まとめて書いたテストは、_想像上の_動作を検証します。ユーザーに見える動作ではなく、物事の_形_をテストするため、実際の変更に対する感度が低くなり、実装を理解する前にテスト構成を決めてしまいます。代わりに垂直スライスで進めてください。テストを一つ書き、実装を一つ行い、これを繰り返します。各テストは、直前のサイクルで得た知見に応じて変化するトレーサーバレットです。

ループのルール

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