TDDとは

TDD(Test-Driven Development)は、テストを先に書いてから実装コードを書く開発手法。Kent Beckが1990年代後半にExtreme Programming(XP)の一部として開発し、現在ではアジャイル開発の中核プラクティスとして広く採用されている。

Kent Beckの言葉を借りれば、TDDの目的は「開発における恐怖を取り除くこと」である。テストが常に存在することで、開発者は自信を持ってコードを変更できる。

テストリストの作成(重要な前段階)

Martin Fowlerが強調するように、Red-Green-Refactorサイクルを始める前にテストケースのリストを作成することが重要である。このリストから1つずつテストを選び、設計の重要なポイントに素早くたどり着けるようにテストの順序を決める。

テストリスト例:
- [ ] 2つの正の数を加算できる
- [ ] 負の数同士を加算できる
- [ ] 0を加算しても結果が変わらない
- [ ] 大きな数を加算してもオーバーフローしない

Red-Green-Refactorサイクル

TDDの基本は3つのフェーズを繰り返すサイクルである。

1. Red(レッド)フェーズ

失敗するテストを書く。

describe('add', () => {
  it('2つの数値を加算する', () => {
    const result = add(2, 3);
    expect(result).toBe(5);
  });
});

この時点ではadd関数は存在しないため、テストは失敗(赤)する。

ポイント:

まず「何を実現したいか」を明確にする
テストは仕様書として機能する
失敗することを確認することで、テストが正しく動作していることを検証する

2. Green(グリーン)フェーズ

テストを通す最小限のコードを書く。

function add(a: number, b: number): number {
  return a + b;
}

ポイント:

「動作する」ことだけを目指す
完璧なコードを書こうとしない
最短経路でテストを通す

3. Refactor(リファクタ)フェーズ

テストが通る状態を維持しながら、コードを改善する。

// 例: より汎用的な実装に改善
const add = (a: number, b: number): number => a + b;

ポイント:

重複を排除する
可読性を向上させる
設計を改善する
テストは常に通る状態を維持する

重要: Martin Fowlerによると、TDDにおける最大の間違いはリファクタリングをスキップすることである。Red-Greenの2ステップだけを行い、リファクタリングを省略すると、コードは断片的で保守しにくいものになる。

TDDの3つの法則

Robert C. Martin(Uncle Bob)が定義した3つの法則:

失敗するテストを書くまで、プロダクションコードを書いてはならない
失敗するテストを必要以上に書いてはならない(コンパイルエラーも失敗)
現在失敗しているテストを通すために必要な最小限のコードしか書いてはならない

テストの種類

単体テスト(Unit Test)

個々の関数やクラスを独立してテストする。

describe('UserService', () => {
  it('ユーザー名が空の場合エラーを投げる', () => {
    expect(() => validateUsername('')).toThrow('ユーザー名は必須です');
  });
});

統合テスト(Integration Test)

複数のコンポーネントの連携をテストする。

describe('UserRepository', () => {
  it('ユーザーを保存して取得できる', async () => {
    const user = await repository.save({ name: 'test' });
    const found = await repository.findById(user.id);
    expect(found.name).toBe('test');
  });
});

E2Eテスト(End-to-End Test)

システム全体を通してテストする。

describe('ユーザー登録フロー', () => {
  it('フォーム入力から登録完了まで', async () => {
    await page.fill('[name="email"]', 'test@example.com');
    await page.click('button[type="submit"]');
    await expect(page.locator('.success')).toBeVisible();
  });
});

テストピラミッド

テストの量と実行速度のバランスを示すモデル。

        /\
       /  \
      / E2E \      <- 少量・遅い・高コスト
     /------\
    /統合テスト\    <- 中程度
   /----------\
  /  単体テスト  \  <- 大量・速い・低コスト
 /--------------\

単体テスト: 最も多く、高速に実行
統合テスト: 中程度の量
E2Eテスト: 最小限、重要なフローのみ

TDDの2つの主要な利点(Martin Fowler)

Martin Fowlerは、TDDには2つの主要な利点があると述べている:

自己テストコード(Self-Testing Code): テストに応答してのみプロダクションコードを書くため、包括的なテストカバレッジが保証される
インターフェースファースト設計: テストを先に書くことで「コードのインターフェースを最初に考える」ことを強制され、インターフェースと実装を分離するという基本的な設計原則を実践できる

TDDのメリット

1. 設計の改善

テストを先に書くことで、使いやすいAPIを設計できる。テストしにくいコードは、使いにくいコードであることが多い。これはMartin Fowlerが強調する「インターフェースファースト設計」の効果である。

2. 回帰バグの防止

既存機能を壊していないことを即座に確認できる。

3. ドキュメントとしての機能

テストコードは「動く仕様書」として機能する。

4. デバッグ時間の削減

小さな単位で検証するため、バグの原因特定が容易になる。

5. 自信を持ったリファクタリング

テストがあることで、安心してコードを改善できる。

TDDのデメリットと対策

1. 初期の学習コスト

対策: 小さなプロジェクトから始め、徐々に慣れる

2. テスト作成の時間

対策: 長期的にはバグ修正時間の削減で相殺される

3. テストの保守コスト

対策: テストも「コード」として品質を保つ

よくある間違い

1. 実装後にテストを書く

TDDではない。「テストファースト」が重要。

2. 一度に多くのテストを書く

1つのテストを書いて通す、を繰り返す。

3. 複雑なテストを書く

テストはシンプルに。1つのテストで1つのことを検証する。

4. 実装の詳細をテストする

振る舞い(behavior)をテストする。内部実装に依存したテストは避ける。

// 悪い例: 実装の詳細に依存
expect(user._privateMethod).toHaveBeenCalled();

// 良い例: 振る舞いをテスト
expect(user.isActive()).toBe(true);

Kent Beckの「Fake It Till You Make It」

Kent Beckは「Test-Driven Development: By Example」で「Fake it till you make it」というテクニックを紹介している。これは:

まず最も単純な実装(ハードコードされた値など)でテストを通す
徐々に一般化していく
最終的に正しい実装に到達する

// ステップ1: Fake it(ハードコード)
function add(a: number, b: number): number {
  return 5; // テストケース add(2, 3) を通すためだけの実装
}

// ステップ2: 一般化
function add(a: number, b: number): number {
  return a + b; // 正しい実装
}

この手法により、小さなステップで確実に前進できる。

実践のコツ

1. 小さく始める

最初は簡単な関数から。複雑なシステムは後から。

2. TODOリストを作る

実装したい振る舞いをリストアップしてから始める。

- [ ] 2つの数値を加算できる
- [ ] 負の数を扱える
- [ ] 0を扱える

3. 明確な命名

テスト名は「何をテストしているか」を明確に。

// 悪い例
it('test1', () => { ... });

// 良い例
it('空文字列を渡すとエラーを投げる', () => { ... });

4. Arrange-Act-Assert(AAA)パターン

テストを3つのセクションに分ける。

it('ユーザーを作成する', () => {
  // Arrange(準備)
  const name = 'test';

  // Act(実行)
  const user = createUser(name);

  // Assert(検証)
  expect(user.name).toBe('test');
});

まとめ

TDDは単なるテスト手法ではなく、設計手法である。テストを先に書くことで:

要件を明確にする
使いやすいAPIを設計する
安心してリファクタリングできる
バグを早期に発見する

最初は時間がかかるように感じるが、長期的にはコード品質の向上とバグ修正時間の削減により、開発効率が向上する。

TDDに対する批判と議論

2014年、David Heinemeier Hansson(Rails作者)が「TDD is Dead」と発言し、Kent Beck、Martin Fowlerとの議論が行われた。この議論から得られた重要な教訓:

TDDは万能ではなく、コンテキストによって有効性が異なる
「体系化された科学」ではなく、自分とチームに合う方法を見つける必要がある
自己テストコードの価値は普遍的だが、TDDを採用するかは状況次第

Martin Fowlerの結論: 「TDDを試し、使い、使いすぎてみて、自分とチームにとって何が機能するかを見つける必要がある。」

参考資料

書籍

Kent Beck「Test-Driven Development: By Example」(2002) - TDDの原典
Robert C. Martin「Clean Code」
Martin Fowler「Refactoring」
James Shore「The Art of Agile Development」

オンラインリソース

Martin Fowler - Test Driven Development
Is TDD Dead? - Kent Beck, Martin Fowler, DHHによる議論
Kent Beck - Test Driven Development: By Example (O'Reilly)