概要

TDD（Test-Driven Development）とは、
**「コードを書き始める前に、そのコードが満たすべき仕様（テスト）を書く」**という開発手法である。

この手法の本質は「テストを書く」ことではなく、
**“思考を仕様ベースで始める”**ことにある。

本稿では、TDDの思想・流れ・メリットと、Vitest＋TypeScriptを用いた最小構成での実践例を交えながら、
**「なぜTDDが設計を変えるのか」**を構造的に解き明かす。

1. TDDとは何か：定義と誤解

TDDは「テストを書いてから実装する」という説明では足りない。
本質は以下の3つの原則にある：

🔴 Red：失敗するテストを書く（仕様を書く）
🟢 Green：テストが通る最小限のコードを書く
🛠️ Refactor：構造を改善し、意味を保つ

実装駆動ではなく、仕様駆動であることがTDDの根幹にある。

2. なぜTDDは「先にテストを書く」のか

実装より先に「何を期待するか」が明確になる
コードが過剰に書かれず、最小限で済む
依存や外部要因を先に意識できるため、疎結合な設計になる

テストは「品質保証」ではなく、**「設計プロンプト」**である

3. 実践：TDDでFizzBuzzを設計する（TypeScript + Vitest）

npm create vite@latest tdd-fizzbuzz --template vanilla-ts
cd tdd-fizzbuzz
npm i
npm i -D vitest

`src/fizzbuzz.ts`（まだ空）

// 空の実装（Green前）

`src/fizzbuzz.test.ts`

import { describe, expect, it } from 'vitest';
import { fizzbuzz } from './fizzbuzz';

describe('fizzbuzz', () => {
  it('returns number for non-multiples of 3 or 5', () => {
    expect(fizzbuzz(1)).toBe('1');
  });
});

Red：テストが失敗する

ReferenceError: fizzbuzz is not defined

Green：最小限の実装を書く

export function fizzbuzz(n: number): string {
  return String(n);
}

再度テスト：

✓ returns number for non-multiples of 3 or 5

Red → Green → 次の仕様を追加

it('returns Fizz for multiples of 3', () => {
  expect(fizzbuzz(3)).toBe('Fizz');
});

it('returns Buzz for multiples of 5', () => {
  expect(fizzbuzz(5)).toBe('Buzz');
});

it('returns FizzBuzz for multiples of 15', () => {
  expect(fizzbuzz(15)).toBe('FizzBuzz');
});

Green：拡張された実装でテストを通す

export function fizzbuzz(n: number): string {
  if (n % 15 === 0) return 'FizzBuzz';
  if (n % 3 === 0) return 'Fizz';
  if (n % 5 === 0) return 'Buzz';
  return String(n);
}

Refactor：構造を洗練させる

条件分岐の順序を整理
再利用可能な条件チェッカーを抽出可能

4. 設計観点から見るTDDの本質

🔍 仕様が明確になることで、設計がシンプルになる
🧩 依存を隔離しやすく、モジュール単位の責務が明確になる
🚦 Red→Greenの明快なフィードバックが、設計の正しさを保証する

実装は「仕様を通すための必要最小限の部品」になる。

5. TDDが破壊する3つの常識

従来の思考	TDD的思考
コード → テスト	テスト → コード
実装のために考える	期待される振る舞いから設計する
UIやAPIをまず作る	使用者視点の仕様から導入する

結語

TDDは「実装をテストする」手法ではない。
それは**“実装されるべき仕様を明示し、それにコードを従わせる構造的思考法”**である。

仕様を書くことで、設計が始まる
実装は仕様を満たす最小限にする
テストは「確認」ではなく、「設計のトリガー」として機能する

TDDとは、
“コードを書き始める前に「何を保証したいか」を思考し、実装を仕様に従属させるための知的戦略である。”