tdd-red-green-refactor

1 行での要約

TDD のサイクル：失敗するテストを書く（レッド）、それを通すための最小限のコードを書く（グリーン）、グリーンの状態を保ちながらリファクタリングする。一度にごく小さなステップを繰り返します。大切なのは「順序」と「最小限」です。どちらも簡単におろそかになります。

このスキルを使う場面

• テストで望ましい結果を明確にできるコードの新しい動作を実装するとき。
• バグを修正するとき — まず回帰テストを書き（tdd-regression-test を参照）、その後で修正します。
• 利用側の視点から API を設計するとき — 最初のテストによって、呼び出し元のコードが何を必要とするのかを考えざるを得なくなります。
• 健全なテストスイートがあり、TDD による摩擦が少ないコードベースで作業するとき。

このスキルを使わない場面

• 何を作るのか、まだ形が定まっていない純粋な探索やスパイク作業。まずスパイクを行い、その後、書き直しをテスト駆動で進めます。
• 使い捨てのスクリプト、一度きりのユーティリティ、または保守する予定のない迅速なプロトタイプ。
• 「テストを書く、ピクセルを変更する、テストが通るのを見る」というサイクルが、メリットよりも負担になる UI の調整。
• 既存のテスト基盤がないコードベースで、1 つの機能のためにハーネスをセットアップするのが割に合わない場合。テストは追加しましょう。できないのに TDD をしているふりをしないでください。

主な内容

レッド — 失敗するテストを書きます。 まだ存在しない動作（またはこれから追加する動作）を対象とした、小さなテストを書きます。実行し、正しい理由で失敗することを確認します。期待する行でのコンパイルエラーやアサーションの失敗であり、3 層も深いところで発生する無関係な NullPointerException ではありません。

グリーン — テストを通すために必要な最小限のコードを書きます。 テストをグリーンにするのに十分な量だけ、本番コードを書きます。最小限であることは重要です — その場で必要なコード上の罪はいくらでも犯して構いません（return "hardcoded" でも問題ありません）。最小限の実装は、テストが正しくつながっていることを確認するための、最も手軽なシグナルです。

リファクタリング — グリーンの状態を保ちながら整理します。 テストという安全網がある状態で、コードの構造を変更します。メソッドを抽出し、変数名を変更し、重複を取り除きます。小さな変更のたびにテストを実行します。レッドになったら、リファクタリングが間違っていたということです。元に戻し、さらに小さく試します。

順序が重要な理由。

• まずレッドにすることで、失敗するテストを書くことになります。本番コードを先に書くと、後から書くテストが実際には不要かもしれません。
• 最小限のグリーンがループの規律です。これがなければ過剰に設計してしまい、ループが引き締まらなくなります。
• 安全網がある状態でのリファクタリングが、設計を改善するタイミングです。テストがなければ、コードを変更するのが怖くなります。テストがあれば、試行錯誤できます。

サイクルの長さ。 1 回のサイクルは数分で終わるべきで、数時間かかるものではありません。1 回のサイクルに約 30 分以上かかる場合、テストが大きすぎます — tdd-child-test を活用しましょう。

TDD は「テストを書くこと」ではありません。 テストを後から書くのはテストです。テストを先に書くのは設計です。順序によってコードがどのように生まれるかが変わります。どちらもテストは作りますが、設計を導くのは一方だけです。

判断のヒント

• サイクルのすべてのステップでテストを実行します。テストの実行をまとめて後回しにしないでください — 迅速なフィードバックが要点です。
• 新機能で最初に書くテストは、小さく、すぐ実行できるものにします。最初のテストが大きい、または遅いと、サイクルがうまく回りません。
• リファクタリングはグリーンのときだけ行います。レッドの状態でのリファクタリングは「壊れたコードを変更すること」であり、もはや TDD ではありません。
• テストより先に本番コードを書いていることに気づいたら、後から書くテストはすでに書いたコードに偏ることになります。いったん止めて、前の段階に戻りましょう。

アンチパターン

• コードを書いた後にテストを書く。 実際に TDD を行ったことのない人が「TDD」と呼ぶことがよくあります。設計を導きません。
• 広い範囲を対象とする大きなテスト。 実行が遅く、グリーンにするのが難しく、失敗しても得られる情報が少なくなります。
• レッドの状態でのリファクタリング。 「設計を直しているので、終わるころにはテストもグリーンになります」。2 つの作業を混同しており、どちらもうまくいきません。
• 最小限のグリーンのステップを飛ばす。 レッドから直接「本格的な」実装に進みます。テストが実際には求めていない複雑さを持ち込むことがよくあります。
• TDD を信条にする。 TDD の効果がないコード（使い捨てのスクリプト、探索的なスパイクなど）にも、TDD を強制します。規律にかかるコストは実際にあります。役立つ場面で負担しましょう。

関連項目

• tdd-identify — サイクルの途中で行き詰まったときに、適切な手法へ導きます。
• tdd-fake-it、tdd-obvious-implementation、tdd-triangulate — 「グリーン」のステップに取り組む3つの方法です。
• tdd-child-test、tdd-one-step-test — レッドテストの規模が大きすぎるときや、どれを選べばよいかわからないときに使います。
• tdd-anti-patterns — TDDがうまくいっていないことを示す兆候です。
• Superpowers の superpowers:test-driven-development — ワークフローレベルのトリガーです。

参考資料

• Kent Beck 著、Test-Driven Development By Example（Addison-Wesley、2002年）— 標準的な参考書です。第I部（Money の例）では、数十回にわたるレッド・グリーン・リファクタリングのサイクルを解説しています。
• Beck の「TDD by Example」講演（たびたび行われています）— 同じ内容を要約したものです。