概要

TDD（Test-Driven Development）では、
まず「失敗するテスト」を書くことからすべてが始まる。

それは単なるルールではなく、設計を「防御的かつ先回り的」に進める知的戦略である。

本稿では、Go言語を使った実装例を通して、
「TDDにおける失敗するテスト」の意義、構造、設計的価値を深掘りする。

1. なぜ「失敗するテスト」を先に書くのか？

✅ 仕様が不明確なまま書かれたコードは、防御不能になる

期待を明文化せずにコードを書くと、バグではなく“未定義”が量産される
TDDは「何が期待されるか」をコードよりも先に言語化するため、設計が意識的になる

✔️ Red（失敗）とは、仕様未満であることを意味する警報である。

2. 実践例：Goで負の数を扱えない平方根関数をTDDで拡張

初期仕様（正の数のみ）

// sqrt.go
package sqrt

import "math"

func Sqrt(n float64) float64 {
	return math.Sqrt(n)
}

// sqrt_test.go
package sqrt

import "testing"

func TestSqrt_PositiveNumber(t *testing.T) {
	got := Sqrt(9)
	want := 3.0
	if got != want {
		t.Errorf("got %v, want %v", got, want)
	}
}

失敗するテストを書く（Red）

func TestSqrt_NegativeNumber(t *testing.T) {
	defer func() {
		if r := recover(); r == nil {
			t.Errorf("expected panic on negative input")
		}
	}()
	Sqrt(-1)
}

実行結果：

--- FAIL: TestSqrt_NegativeNumber
    sqrt_test.go:...: expected panic on negative input

3. テストから見えてくる「設計の空白」

現時点の仕様では、負の数に対する振る舞いが未定義（math.SqrtはNaNを返す）
TDDは「仕様の抜け漏れ」をRedであぶり出す
ここで**「何を期待するか」＝「何をガードすべきか」**を定義する

4. Green – ガードを導入して通る実装に

func Sqrt(n float64) float64 {
	if n < 0 {
		panic("negative input not allowed")
	}
	return math.Sqrt(n)
}

テスト結果：

✓ TestSqrt_PositiveNumber
✓ TestSqrt_NegativeNumber

5. Redは「バグ検知」ではなく「仕様強化」

Redを書かなければ見逃されていたかもしれないもの

不具合の種	設計的ガード
nullや0除算	明示的に制御すべき入力
境界値	テストを書くことで意識が向く
不正状態	Redを先に書くことで構造が強化される

設計判断フロー

① この仕様に対して、失敗してほしいパターンはあるか？ → YES → Redを書く

② 書いたRedが、仕様として意味を持つか？ → YES → 実装に意味を与える

③ Redが通った後、実装に過剰なものが残っていないか？ → NO → Greenを最小化

④ 想定外の入力は、定義しておくべきか、黙殺するか？ → YES → テストで明示

よくあるミスと対策

❌ 正常系しかテストを書かない

→ ✅ 仕様が単線化し、想定外の挙動を許容する
→ 🔁 Redで失敗系・境界系・例外系を先に書くことで、設計に幅が生まれる

❌ Redを「ただ通すためだけ」の作業になる

→ ✅ Redは「何を恐れているか」を意図として書く。思想を持った失敗を。

結語

TDDにおける「Red」は、単なる失敗ではない。
それは**“まだ満たされていない仕様がある”というシグナルであり、設計を先鋭化させる対話の起点”**である。

仕様の「抜け」は、Redによって炙り出される
実装の「過剰」は、Greenによって抑制される
構造の「曖昧さ」は、Refactorによって洗練される

TDDとは、
“仕様の不完全さをRedで照らし、進化するシステムの防壁を構築する戦略である。”