テスト駆動開発 — RED-GREEN-REFACTORをAIと回す

テストを先に書く。この一見遠回りなアプローチが、AIコーディングにおいて最も強力な品質保証手法となる。

なぜTDDとAIの相性がよいのか

AIが書いたコードには、常に「本当に正しいのか？」という疑問がつきまとう。LLMは統計的にもっともらしいコードを生成するが、それが仕様通りに動く保証はない。

テストは、その保証を提供する。

テストを先に書いておけば、AIが生成したコードが「仕様を満たしているかどうか」を自動的に検証できる。テストが通れば合格、通らなければ不合格。AIの出力を「信じる」のではなく「検証する」ワークフローが実現する。

RED-GREEN-REFACTOR サイクル

RED — テストを先に書く

> BMI計算関数のテストを先に書いて。以下の仕様:
> - 身長170cm、体重70kgの場合、BMI 24.2を返す
> - BMI 18.5未満は「低体重」
> - BMI 25以上は「過体重」
> - 身長0以下はエラー

Claude Codeがテストファイルを生成する。

describe("calculateBMI", () => {
  test("正常な入力でBMIを計算する", () => {
    const result = calculateBMI(170, 70);
    expect(result.bmi).toBeCloseTo(24.22, 1);
  });

  test("低体重を判定する", () => {
    const result = calculateBMI(170, 50);
    expect(result.category).toBe("低体重");
  });

  test("不正な入力でエラーを投げる", () => {
    expect(() => calculateBMI(0, 70)).toThrow();
  });
});

テストを実行する。当然、失敗する（まだ実装がないから）。

> テストを実行して

FAIL  ❌ calculateBMI is not defined

これが RED の状態。

GREEN — 最小限の実装を書く

> テストが通る最小限の実装を書いて

Claude Codeがテストを通すための実装を生成し、テストを再実行する。

PASS  ✅ All tests passed

これが GREEN の状態。

REFACTOR — リファクタリング

> テストを維持したまま、コードをリファクタリングして

テストが通り続けることを確認しながら、コードの品質を改善する。

/tdd スキルの活用

> /tdd

/tdd スキルを使うと、このサイクル全体がガイド付きで進む。

1. インターフェースの設計を促す
2. テストの作成を誘導
3. テスト実行と失敗確認
4. 実装の作成
5. テスト通過の確認
6. リファクタリングの提案
7. カバレッジ80%以上の達成確認

tdd-guide エージェント

より厳格なTDDを求める場合は、tdd-guide エージェントを使う。

このエージェントは以下を強制する。

• テストファイルが実装ファイルより先に作成されること
• テストが一度失敗してから実装に進むこと
• カバレッジが80%以上であること
• ユニットテスト、統合テスト、E2Eテストの3層構造

テストフレームワーク

実践例: 医療計算関数のTDD

小児の体表面積（BSA）を計算する関数をTDDで作ってみよう。

> 以下の仕様でTDDで実装して:
>
> 関数名: calculateBSA
> 入力: 体重(kg)、身長(cm)
> 出力: 体表面積(m²)
> 計算式: Mosteller式 = √(体重 × 身長 / 3600)
>
> テスト条件:
> - 体重10kg、身長75cm → BSA 0.456 m²
> - 体重0以下はエラー
> - 結果は小数点第3位まで

Claude Codeは以下のサイクルを自律的に回す。

1. テストファイル作成 → テスト実行（RED）
2. 実装ファイル作成 → テスト実行（GREEN）
3. リファクタリング提案 → テスト実行（引き続きGREEN）
4. カバレッジレポート表示