概要
TDD（Test-Driven Development）には、明文化された三原則が存在する。
これらは単なる「テストの手順」ではなく、
**“設計の複雑性を制御し、進化に耐えるコードを書くための制約”**である。
本稿では、Ruby + RSpec による実践を通して、
TDD三原則の意味と威力を構造的に掘り下げる。
1. TDD三原則とは何か
Kent Beck によって定義された以下の三原則がTDDのコアにある：
原則①：失敗するテストを書くまで、プロダクションコードを書いてはならない
→ テストファースト。何を満たすべきかを先に書く
原則②：テストが失敗したら、それを通すためだけのコードを書く
→ 最小限の実装。余計な処理を先回りしない
原則③：重複を除去しながらリファクタする
→ 動作を保ちつつ、設計を洗練させる
2. 実践：TDDで文字列の回文判定関数を書く
ステップ1：Red – 仕様を書く
# palindrome_spec.rb
require './palindrome'
RSpec.describe '#palindrome?' do
it 'returns true for "madam"' do
expect(palindrome?('madam')).to eq true
end
end
ステップ2：Green – テストを通すためだけの実装
# palindrome.rb
def palindrome?(str)
true
end
- ✅ 原則②に則り、最低限のコードでテストを通す
ステップ3：Red – もう1つの仕様を追加
it 'returns false for "hello"' do
expect(palindrome?('hello')).to eq false
end
Green – 振る舞いを満たす実装
def palindrome?(str)
str == str.reverse
end
ステップ4：Refactor – 冗長性を排除し構造を磨く
この例ではコードは既に簡潔だが、他のケースでは：
- 条件の共通化
- 変数抽出
- メソッドの分割
などを実施する。
3. 原則の力：なぜ「少しずつ」進めるのか
- 実装前に期待（仕様）を明確化することで、責務がシンプルになる
- 過剰設計を防ぎ、“使われるコード”のみを書く習慣がつく
- 小さなテストサイクルが、信頼性と可読性を継続的に確保
👉 三原則とは、「余計なことをしない」ための思考のフレームワーク
4. 三原則 × 設計改善のフロー
| ステップ | 内容 | 設計効果 |
|---|---|---|
| 🔴 Red | 仕様を書く | 要求の明示 |
| 🟢 Green | 必要最低限でテストを通す | 実装の最小化 |
| 🔁 Refactor | 動作を保ったまま改善する | 構造の洗練・再利用性の向上 |
設計判断フロー
① この処理に対してテストが書けるか？ → NO → 設計が不明確かもしれない
② テストのために多くの依存を作っていないか？ → YES → 責務が大きすぎる
③ 「仕様 → 実装 →改善」の順序が保たれているか？ → YES → 三原則通り
④ テストが書きやすい設計になっているか？ → YES → 結合が適切に制御されている
よくあるミスと対策
❌ 先に実装を書き、後からテストを合わせる
→ ✅ テストは 設計そのものを定義する仕様書。後付けでは本末転倒
❌ テストを通すために「一発で完璧な実装」をしようとする
→ ✅ Greenは「動けばよい」。Refactorで設計する習慣をつける
❌ テストケースが冗長で読みづらい
→ ✅ 共通化や条件の分離をRefactorステップで整理
結語
TDD三原則は、コードを書くためのルールではない。
それは**“コードの意味と目的を明確にするための、思考と設計のリズム”**である。
- 最初に仕様を書く
- それを通す最小限の実装を書く
- 継続的に構造を洗練する
TDDとは、
“機能するコードではなく、意味を持つ構造をつくるための設計原則である。”