tdd

mattpocock/skills の skills/engineering/tdd/SKILL.md（4ae2317）に含まれる workflow-axa。MIT（LICENSE）。以下の上流テキストは変更されていません。末尾の workflow-axa による適用は、内容が矛盾する場合に優先されます。

テスト駆動開発

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

コードベースを調べる際は、テスト名とインターフェースの用語がプロジェクトのドメイン用語と一致するように、GLOSSARY.md（存在する場合）を読み、作業対象の領域にある ADR を遵守してください。

優れたテストとは

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

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

シーム：テストする場所

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

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

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

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

アンチパターン

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

ループのルール

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

---

workflow-axa の適応

• シームはすでに合意されています。 workflow-specify では、各チケットのテストシームを記録し、ゲート2で承認を得ます。それらを使用し、本当に新しいシームが必要な場合にのみ確認してください。
• 用語。 プロジェクトの CONTEXT.md（または GLOSSARY.md）と、存在する場合は ADR を確認してください。
• 参照先。 このテキストで Skill ツールを使って codebase-design または code-review を呼び出すよう指示されている場合は、代わりに ../codebase-design/SKILL.md または ../code-review/SKILL.md（このパッケージ内のファイル）を読んでください。
• 誠実さ。 テスト基盤がない場合はブロッカーです。テストランナーをインストールしたり、テストを弱めたり、実際には行っていないレッド／グリーンサイクルを報告したりしないでください。ドキュメントや設定に関するチケットでは、記載された契約を確認してください。