テスト駆動開発（TDD）

TDD とは何か

テスト駆動開発（Test-Driven Development）は、実装コードより先にテストコードを書く開発手法です。Kent Beck が 1990 年代後半に Extreme Programming（XP）の中で体系化し、2002 年に書籍として出版しました。

手法の核心はシンプルです。「動作する最小限の実装を、失敗するテストが要求する形で積み上げる」。これにより、設計の過剰複雑化を防ぎ、変更に強いコードベースが自然に育ちます。

Red → Green → Refactor サイクル

主なテストフレームワーク

言語ごとに標準的なフレームワークが確立されています。以下は 2025 年時点で広く使われているものです。

生成 AI 時代になぜ注目されるか

AI がコードを書く時代になったことで、TDD の価値がむしろ上がっています。3 つの理由があります。

AI へのテストファーストの指示例

次のプロンプトは特定ツール専用ではありません。Claude Code / Cursor / GitHub Copilot / Windsurf / Gemini CLI など、お使いの AI コーディングアシスタントの入力欄にそのまま貼り付けて使えます。テストコードを一緒に渡すことで、AI が何を作ればよいかを取り違えにくくなります。

以下のテストをすべてパスする最小限の実装を src/fizzbuzz.ts に書いてください。
テスト以外の機能は先回りして実装しないでください。

--- test/fizzbuzz.test.ts ---
import { fizzbuzz } from "../src/fizzbuzz";

describe("fizzbuzz", () => {
  it("3の倍数のとき Fizz を返す", () => {
    expect(fizzbuzz(3)).toBe("Fizz");
  });
  it("5の倍数のとき Buzz を返す", () => {
    expect(fizzbuzz(5)).toBe("Buzz");
  });
  it("15の倍数のとき FizzBuzz を返す", () => {
    expect(fizzbuzz(15)).toBe("FizzBuzz");
  });
});

準備と気をつけること

環境の前提を確認する

本ページのハンズオンは JavaScript / TypeScript と Vitest を使います。始める前に Node.js（サーバー側でも動く JavaScript 実行環境。npm というパッケージ管理ツールが同梱されます）が入っているか確認してください。ターミナルで次を実行し、バージョン番号が表示されれば準備完了です。

node -v   # 例: v20.11.0 のように表示されれば OK
npm -v    # 例: 10.2.4 のように表示されれば OK

AI コーディングアシスタント（例えば Claude Code、Cursor、GitHub Copilot、Windsurf、Gemini CLI など）のいずれかが使える状態になっていれば、後半の AI 連携ステップも試せます。必須ではなく、手で実装する形でも一通り体験できます。

ハンズオン: お手元の AI ツールで FizzBuzz を TDD

以下の手順に沿って、FizzBuzz を TDD で実装します。FizzBuzz は、1 から順に数を出力し、3 の倍数なら「Fizz」、5 の倍数なら「Buzz」、両方の倍数（15 の倍数）なら「FizzBuzz」に置き換える、テストの練習として定番の小さな課題です。エディタは VS Code / Cursor / JetBrains 系など好きなもので、AI アシスタントも Claude Code / Cursor / GitHub Copilot / Gemini CLI などお使いのもので構いません。まずは手を動かして Red と Green を体感してみてください。

mkdir tdd-fizzbuzz && cd tdd-fizzbuzz
npm init -y

{
  "name": "tdd-fizzbuzz",
  "version": "1.0.0",
  "type": "module",
  "scripts": {
    "test": "vitest",
    "test:run": "vitest run"
  },
  "devDependencies": {
    "vitest": "^2.0.0",
    "typescript": "^5.0.0"
  }
}

npm install
mkdir src test

// describe: 関連するテストをひとまとめにする箱（テスト対象の名前を書く）
// it: 1つの振る舞いを確認するテスト1件（日本語で仕様を書ける）
// expect(...).toBe(...): 実際の値が期待値と一致するかを検証する
import { describe, it, expect } from "vitest";
// まだ存在しない実装を import しておく（この時点では読み込みに失敗する）
import { fizzbuzz } from "../src/fizzbuzz";

describe("fizzbuzz", () => {
  it("3の倍数のとき Fizz を返す", () => {
    // Given: 3 という入力に対して（前提）
    // When: fizzbuzz(3) を呼び出したとき（操作）
    // Then: "Fizz" が返ってくることを期待する（期待結果）
    expect(fizzbuzz(3)).toBe("Fizz");
  });

  it("5の倍数のとき Buzz を返す", () => {
    // Given 5 / When fizzbuzz(5) / Then "Buzz"
    expect(fizzbuzz(5)).toBe("Buzz");
  });

  it("15の倍数のとき FizzBuzz を返す", () => {
    // Given 15（3と5の両方の倍数）/ When fizzbuzz(15) / Then "FizzBuzz"
    expect(fizzbuzz(15)).toBe("FizzBuzz");
  });

  it("それ以外のとき数値の文字列を返す", () => {
    // Given 倍数でない数 / When fizzbuzz(n) / Then その数の文字列
    expect(fizzbuzz(1)).toBe("1");
    expect(fizzbuzz(7)).toBe("7");
  });
});

npm run test:run

ERROR: Cannot find module '../src/fizzbuzz'
FAIL  test/fizzbuzz.test.ts

// n を受け取り、FizzBuzz のルールに従った文字列を返す関数
// : number は引数の型、: string は戻り値の型（TypeScript の型注釈）
export function fizzbuzz(n: number): string {
  // % は割った余り。余り0 = 割り切れる = 倍数。
  // 15の判定を先に置くのが要点。先に3で拾うと15が "Fizz" になってしまう
  if (n % 15 === 0) return "FizzBuzz";
  if (n % 3 === 0) return "Fizz";
  if (n % 5 === 0) return "Buzz";
  // どの倍数でもなければ、数値を文字列に変換して返す
  return String(n);
}

npm run test:run

 ✓ test/fizzbuzz.test.ts (4)
   ✓ 3の倍数のとき Fizz を返す
   ✓ 5の倍数のとき Buzz を返す
   ✓ 15の倍数のとき FizzBuzz を返す
   ✓ それ以外のとき数値の文字列を返す

Test Files  1 passed (1)
Tests       4 passed (4)

  it("0 または負の数のとき Invalid を返す", () => {
    // Given 0 や負の数 / When fizzbuzz(n) / Then "Invalid"
    expect(fizzbuzz(0)).toBe("Invalid");
    expect(fizzbuzz(-1)).toBe("Invalid");
  });

export function fizzbuzz(n: number): string {
  // 追加した仕様。異常な入力を最初に弾く（ガード節）
  if (n < 1) return "Invalid";
  if (n % 15 === 0) return "FizzBuzz";
  if (n % 3 === 0) return "Fizz";
  if (n % 5 === 0) return "Buzz";
  return String(n);
}

test/fizzbuzz.test.ts のすべてのテストをパスする最小限の実装を
src/fizzbuzz.ts に書いてください。
テストで要求されていない機能は追加しないでください。

関連手法との比較

TDD は単体テストを起点にした手法ですが、テストには複数の層と目的があります。

参考資料

• Kent Beck — Test-Driven Development: By Example（2002）
  TDD の創始者による原典。マネーサンプルを通じて Red→Green→Refactor を体験できます。Amazon.co.jp で入手可能（英語版）。
• Martin Fowler — TestDrivenDevelopment（bliki）
  TDD の概念と意義を簡潔にまとめた解説。Refactoring の著者でもある Fowler による整理です。
• t_wada — 「テスト駆動開発」翻訳者・和田卓人さんのブログ
  日本語で TDD を広めた第一人者。書籍翻訳者として Kent Beck の意図を正確に伝えてきた方です。ブログやスライドが参考になります。
• t_wada — 生成 AI と TDD（Zenn）
  生成 AI 時代における TDD の位置づけを論じた記事。AI がコードを書く時代にテストファーストがなぜ重要かを掘り下げています。
• Statsig — What is Test-Driven Development (TDD)?
  TDD のサイクル・メリット・デメリットを実例付きで解説した英語記事。現代的な開発環境での実践例が参考になります。
• Kent Beck — Canon TDD（2023）
  創始者本人が「本来の TDD とは何か」を改めて定義し直した記事。テストリストを作り、1件ずつ Red→Green→Refactor する正統な手順が読めます。誤解されがちな TDD 像を本人が正しています。
• Vitest 公式ドキュメント
  本ハンズオンで使用する TypeScript 向け高速テストフレームワーク。Jest 互換の API を持ちながら Vite のエコシステムと統合されています。導入方法・mock・非同期テストの書き方が読めます。
• Jest 公式ドキュメント（日本語）
  JavaScript / TypeScript で最も広く使われるテストフレームワークの日本語ドキュメント。matcher やモックの API が体系的に読めます。Vitest とほぼ同じ書き味です。
• xUnit の歴史（Wikipedia）
  Kent Beck が Smalltalk 用に作った SUnit を起点に、JUnit・NUnit・pytest など各言語の単体テスト基盤へ広がった系譜が読めます。今日のテストフレームワークの共通構造（テストケース・アサーション・テストランナー）の由来が分かります。
• t_wada — TDD Boot Camp 基調講演スライド
  和田卓人さんが TDD の考え方をライブコーディングで示す定番講演の資料。Red→Green→Refactor を実演で追え、初学者が最初に見る教材として広く薦められています。

よくあるテストパターン集

実務でよく書くテストのパターンをまとめています。FizzBuzz のような単純な関数から、非同期処理・例外処理まで、型ごとのひな形として使えます。

正常系と異常系を分ける

import { describe, it, expect } from "vitest";
import { divide } from "../src/calculator";

describe("divide", () => {
  // 正常系: 期待する結果を確認する
  it("10 ÷ 2 = 5 を返す", () => {
    expect(divide(10, 2)).toBe(5);
  });

  it("負の数でも正しく割る", () => {
    expect(divide(-10, 2)).toBe(-5);
  });

  // 異常系: 不正入力に対して適切に例外を投げるか
  it("0 除算のとき Error を投げる", () => {
    expect(() => divide(10, 0)).toThrow("Division by zero");
  });
});

非同期関数のテスト

API 通信のように結果が返るまで待つ処理を非同期処理と呼びます。テストでは async / await で完了を待ちます。実際の API を呼ぶとテストが遅く不安定になるため、モック（本物の代役として決まった値を返す偽物）に差し替えます。vi.fn() はモック関数を作る道具、vi.stubGlobal はグローバルな fetch を一時的にモックへ置き換える指定です。似た用語のスタブは「決まった値を返すだけの代役」を指し、モックは「呼ばれ方まで検証できる代役」を指します。用語は現場によって曖昧に使われることもあります。

import { describe, it, expect, vi } from "vitest";
import { fetchUser } from "../src/api";

describe("fetchUser", () => {
  it("ID を渡すとユーザーオブジェクトを返す", async () => {
    // fetch をモック（外部 API を呼ばない）
    vi.stubGlobal("fetch", vi.fn().mockResolvedValue({
      ok: true,
      json: async () => ({ id: 1, name: "山田" }),
    }));

    const user = await fetchUser(1);
    expect(user.name).toBe("山田");
  });

  it("API が 404 のとき null を返す", async () => {
    vi.stubGlobal("fetch", vi.fn().mockResolvedValue({
      ok: false,
      status: 404,
    }));

    const user = await fetchUser(99);
    expect(user).toBeNull();
  });
});

境界値テスト

ビジネスロジックは境界値（上限・下限・境目）でバグが出やすい。この3点を必ずテストします。

import { describe, it, expect } from "vitest";
import { isAdult } from "../src/ageCheck";

describe("isAdult", () => {
  it("17歳は false を返す（境界の手前）", () => {
    expect(isAdult(17)).toBe(false);
  });

  it("18歳は true を返す（境界）", () => {
    expect(isAdult(18)).toBe(true);
  });

  it("19歳は true を返す（境界の次）", () => {
    expect(isAdult(19)).toBe(true);
  });

  it("負の年齢は false を返す（想定外入力）", () => {
    expect(isAdult(-1)).toBe(false);
  });
});

演習課題

FizzBuzz の次に取り組む題材です。仕様を自分で読み解き、テストを先に書いてから実装してください。

it("8文字未満は weak", () => expect(checkPassword("abc123")).toBe("weak"))
it("英字+数字8文字以上は medium", () => expect(checkPassword("Abc12345")).toBe("medium"))
it("記号を含む8文字以上は strong", () => expect(checkPassword("Abc1234!")).toBe("strong"))
it("空文字は weak", () => expect(checkPassword("")).toBe("weak"))

interface CartItem {
  price: number;
  qty: number;
  taxRate: number; // 0.1 = 10%
}

test/[ファイル名].test.ts のすべてのテストをパスする
最小限の実装を src/[ファイル名].ts に書いてください。
テストで要求されていない機能は追加しないでください。
実装後に npm run test:run を実行して結果を確認してください。

よくある質問

研修中や実務導入初期に多く出る質問をまとめています。

チームへの導入ガイド

個人での習得が済んだら、チームへ広げる段階です。一度に全員に強制しても定着しません。段階的に広げる方法を示します。

よくある抵抗への対応