概要

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とは、
“機能するコードではなく、意味を持つ構造をつくるための設計原則である。”