TDD: レッド/グリーン リファクタリングを使用して AI に小さなステップを強制する

障害モード: 「AI は正しい動作をしますが、実行できません」

Matt の講演の 3 番目の失敗モード: 方向は正しいが、機能しない。

最も直接的な解決策は、AI 用のフィードバック インフラストラクチャをインストールすることです。

• TypeScript (静的型付けはありません クレイジーです)
• LLM がブラウザにアクセスしてページを単独で表示できるようにする
• 自動テスト

しかし、Matt は、このフィードバックがインストールされていても、LLM はうまく機能しないということを観察しました。一度に 500 行を書いてから、「ああ、タイプチェックをしなければいけない」と考える傾向があります。これは、プラグマティック プログラマーが ヘッドライトを追い越す と呼ぶものです。ヘッドライトが照らすよりも速く運転し、壁にぶつかるのは時間の問題です。

"The rate of feedback is your speed limit, which means you should be testing as you go, taking small deliberate steps. And the AI by default is really not very good at that."

この問題を解決するには、AI をツール レベルで段階的に強制的に停止する必要があります。 Matt の答えは、TDD - 最初にテストするとチェックポイントが強制される可能性があるです。

古典的な理論: ケント・ベックの赤と緑の再構築

TDD の標準リズムは、Kent Beck の 2003 年の著書『テスト駆動開発: 例による』で次のように定義されています。

1. 赤: 失敗したテストを作成します (何をすべきかを説明します)
2. 緑: テストに合格するのに十分な最小のコードを作成します。
3. REFACTOR: テスト保護下のコード構造を改善する

各ループは非常に短く、数分程度です。すべてのステップで自動チェック (テストの合格/不合格) が行われます。

Matt はこのリズムを直接踏襲していますが、彼の SKILL.md は アンチパターン について話すのに多くの時間を費やしています。これが核心です。

主要なアンチパターン: 水平方向にスライスされた赤と緑

多くの人は、TDD とは「最初にすべてのテストを作成し、次にすべての実装を作成する」ことを意味すると考えています。 Matt は、SKILL.md のこれは間違っていると直接述べています。

WRONG (horizontal slicing):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

RIGHT (vertical slicing via tracer bullets):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3
  ...

なぜ水平が間違っているのでしょうか？ SKILL.mdさんは次の3つの理由を挙げています。

1. Tests written in bulk test imagined behavior, not actual behavior
2. You end up testing the shape of things (data structures, function signatures) rather than user-facing behavior
3. Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine

人間の格言: すべてのテストを一度に書くことは、実際のコードではなく、頭の中にあるものをテストしていることになります。 impl3 を作成すると、test1 の設計が間違っていることに気づきますが、この時点では、test2/test3/test4 はすべて間違った設計に結合されています。戻って変更を加えます。

正しいアプローチは、1 つの実装をテストし、1 つのペアを作成した後で次のペアを開くことです。各ペアが完了し、この実装から何かを学んだ後、想像力ではなく実際の経験に基づいて次のテストのペアを設計できます。

スキルの全文構造

engineering/tdd/SKILL.md は、TDD 自体に多くのニュアンスがあるため、Matt が書いた最も長いスキルの 1 つです。コア構造は次のとおりです。

哲学

Core principle: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.

Good tests are integration-style: they exercise real code paths through public APIs. They describe what the system does, not how it does it. A good test reads like a specification.

Bad tests are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly). The warning sign: your test breaks when you refactor, but behavior hasn't changed.

診断を思い出してください: 内部関数の名前を変更すると、テストはひざまずきます。その場合、このテストは動作ではなく実装をテストすることになり、これは悪いテストです。

ワークフロー (チェックリスト付き)

1. Planning

コードを記述する前にユーザーと調整します。

[ ] Confirm with user what interface changes are needed
[ ] Confirm with user which behaviors to test (prioritize)
[ ] Identify opportunities for deep modules (small interface, deep impl)
[ ] Design interfaces for testability
[ ] List the behaviors to test (not implementation steps)
[ ] Get user approval on the plan

重要な質問: 「パブリック インターフェイスはどのようなものであるべきですか?テストするのに最も重要な動作はどれですか?」

"You can't test everything. Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case."

これは非常に直観に反するものです。デフォルトでは、AI はすべてのエッジ ケースを網羅しようとしますが、Matt は 優先度 を強調し、すべての動作が測定に値するわけではなく、コア パスに火力を集中させます。

2. Tracer Bullet

1つのことを検証する**テストを作成します。

RED:   Write test for first behavior → test fails
GREEN: Write minimal code to pass → test passes

これは「曳光弾」です。最初に発射して照準を確認してください。 Matt 氏は、この作業は エンドツーエンド であるべきであると強調しました。つまり、最初にスキーマを作成し、次に API を作成し、次に UI を作成するのではなく、スタック全体を通る最も細いパスをカットする必要があると強調しました。

3. Incremental Loop

後続の動作ごとに赤→緑を繰り返します。

RED:   Write next test → fails
GREEN: Minimal code to pass → passes

ルール:

• 一度に 1 つのテスト
• 現在のテストに合格するのに十分なコードのみを記述します
• 将来のテストを予測しないでください
• テストは観察可能な動作に焦点を当てます

「予測しない」ことが特に重要です。 AI は、「とにかくこの関数は X をサポートする必要があるので、ついでに追加しましょう」と考えずにはいられません。これにより、水平方向のスライスが開始されます。

4. Refactor

すべてのテストに合格したら、リファクタリングの機会を探します。

[ ] Extract duplication
[ ] Deepen modules (move complexity behind simple interfaces)
[ ] Apply SOLID principles where natural
[ ] Consider what new code reveals about existing code
[ ] Run tests after each refactor step

Never refactor while RED. Get to GREEN first.

赤のリファクタリング = テストとコードを同時に変更 = テストが間違っているのかコードが間違っているのかわかりません。 最初にグリーン、次にリファクタリング。

Per-Cycle Checklist

赤と緑の各サイクルの終わりに、マットは AI に次の自己チェックを依頼します。

[ ] Test describes behavior, not implementation
[ ] Test uses public interface only
[ ] Test would survive internal refactor
[ ] Code is minimal for this test
[ ] No speculative features added

これら 5 つのポイントは、不適切なテストと過剰実装を特定するために使用されます。 AI セルフチェックにより、最も一般的な間違いを防ぐことができます。

実際の使用: 発行から PR まで

/tdd は、Matt のワークフローの /to-issues からの次のステップです。垂直スライスの問題を考慮すると、プロセスは次のようになります。

你: 实现 issue #43
    ↓
/tdd
    ↓
Claude 读 issue acceptance criteria
    ↓
Claude 探索代码库 → 找到 CONTEXT.md → 用项目术语
    ↓
Planning 阶段:
    - 列出准备改的接口
    - 列出准备测的行为（按优先级排序）
    - 让你点头
    ↓
Tracer Bullet:
    - RED: 写第一个测试（基于 acceptance criteria 第 1 条）
    - 跑测试，确认 fail
    - GREEN: 写最小实现
    - 跑测试，确认 pass
    ↓
Incremental Loop:
    - 每个 acceptance criteria 一个 RED→GREEN
    ↓
Refactor:
    - 看 deep module 提取机会
    - 每次重构后跑全套测试
    ↓
PR

赤と緑のサイクルごとに AI が停止し、「テストは失敗しました」/「テストは成功しました。差分は次のとおりです」というステータスが表示されます。 これらの一時停止は、ヘッドライトを追い越すための解毒剤です - AI には一度に 1,000 行をレイアウトする可能性はありません。

モックについて: マットの強い意見

SKILL.md はモックの危険性について特に言及しており、別の mocking.md も提供しています。核となるアイデア:

"Bad tests... mock internal collaborators."

内部協力者をモック化 = テストと実装が 1:1 で結合 = リファクタリング時にテスト チームがひざまずく。 Matt の好みは 統合スタイルのテストです。実際のデータベース (メモリ内またはテストコンテナ)、実際の HTTP (MSW)、および実際のファイル システム (tmp dir) を使用してみてください。本当に高価な境界または不安定な境界 (OpenAI API の呼び出しなど) でのみモックを実行してください。

これは多くのチームの現状とは対照的です。ほとんどのコード ライブラリは単体テストでいっぱいで、実際のコードよりもモックの方が多いのです。 Matt はスピーチで次のように判断しました: 優れたコード ベース = コード ベースのテストが簡単。テストするために多数のモックを作成する必要がある場合は、コード構造に問題があることを意味するため、最初にアーキテクチャを変更する必要があります (/improve-codebase-architecture に進みます)。

AI時代におけるTDDの新たな意義

ケント・ベックが 23 年前にその本を書いたとき、TDD の中心的な利点は「人々が間違ったコードを書かなくなること」でした。 AI 時代において、TDD には次のような追加の意味があります。

これは、AI が理解できる唯一の「成功基準」です。

マットはスピーチの後半でカルパシーの知恵の言葉を引用しました。

「成功基準」の最良の形式は テスト です。これは機械検証可能でバイナリであり、議論の余地はありません。 AI にテスト スイートを与えて「合格させてください」とすることは、AI に要件の説明を与えて「実装してください」と与えるよりも 10 倍信頼性が高くなります。

したがって、/tdd は単なる品質保証ツールではなく、エージェント ループへの入力インターフェイスでもあります。赤と緑の各サイクルは、完全な「インプット→アクション→フィードバック」です。 AI はサイクル内でこの実装の実際の状況を学習し、次のサイクルではより正確になります。

インストールと使用方法

npx skills@latest add mattpocock/skills

tdd + setup-matt-pocock-skills を確認してください。

現在 Codex を主に使用している場合は、インストール製品を .agents/skills/ に引き継ぎ、プロジェクト レベルのワークフロー、テスト コマンド、発行トラッカー ルールを AGENTS.md に書き込みます。 Matt の /tdd の本質は赤と緑のリファクタリング サイクルであり、クロード コードとは関係ありません。

呼び出し方法:

• 直接: /tdd - 現在の会話コンテキストから何を測定するかを推測させます
• 問題を取得: /tdd implement #43 - 問題を取得して開きます。
• バグを修正: /tdd reproduce this bug then fix it - まずバグを再現できる失敗したテストを作成し、それから修正します。

注意事項

すべてのタスクに適しているわけではありません。 1 回限りのスクリプト、プレイグラウンド探索コード、UI の微調整 - TDD は使用しないでください。ペースが遅くなります。 Matt 自身も、TDD は「永続的な価値があり、保守が必要な」コードに適していると述べています。

最初にテスト インフラストラクチャを準備します。プロジェクトにテスト フレームワーク (Vitest / Jest / Playwright など) がインストールされていない場合は、最初にテスト フレームワークをインストールしてから /tdd を使用します。それ以外の場合は、最初にテスト フレームワークがインストールされますが、そのステップには多くの質問があります。

e2e テストを自動的に追加させないでください。 e2e はゆっくりで歯切れがよく、TDD のリズムは分単位です。 /tdd のデフォルトは e2e ではなく統合テストですが、「ユニット + 統合のみ、e2e ではない」と明示的に指定できます。

再建段階は最も制御不能になりやすい段階です。 AI が GREEN ステータスを取得すると、熱心にさまざまなものをリファクタリングします。それを見つめ、各リファクタリングの後にテストを実行します。この部分はAI逸脱のリスクが高い領域です。

参考リソース

次の記事: コードベース アーキテクチャの改善: 浅いモジュールを深いモジュールに再構築する - 定期的なメンテナンスにより、コード ベースで AI を長期的に実行できるようになります。