ReactでのTDD実例に学ぶ代表的なTDDパターン

1. テスト駆動開発（TDD）とは

テスト駆動開発（TDD: Test Driven Development）は、ソフトウェアの品質向上や開発効率の向上を目的とした手法です。最大の特徴は、実装より先にテストを書く（テストファースト）ことです。

TDDの基本サイクル
テストを先に書く（Red）
実装する機能の仕様や振る舞いを明確にするため、まずはテストコードを作成します。この段階では未実装のためテストは失敗（Red）となります。

最小限の実装を行う（Green）
テストを通す（Green）ために、必要最小限のコードを書きます。複雑なロジックは後回しにして、とにかくテストを通すことを優先します。

リファクタリング（Refactor）
テストが全て通る状態を保ちつつ、コードの重複や可読性の問題を改善します。テストが“安全網”の役割を果たし、機能の正しさを担保してくれます。

上記の「Red → Green → Refactor」サイクルを小さく回すことで、段階的な機能拡張と高品質なコードの両立が可能となります。

2. 代表的なTDDパターン

Red-Green-Refactorパターン

TDDを象徴する基本パターン。失敗するテスト（Red）を起点に、最小限の実装（Green）で通し、最後にリファクタリング（Refactor）を行うという流れを繰り返します。
Triangulation（三角測量）パターン

単一のテストでは抽象化しづらい場合に、異なる視点や条件のテストを複数追加し、実装に汎用性を持たせていく手法です。

Fake Itパターン

最初はハードコーディングなどでテストを通し、後からより汎用的な実装に置き換えていく手法です。仕様や要件が明確でないときや、段階的にロジックを洗練させたい場合に有効です。

Obvious Implementationパターン

明らかに正しい実装がある場合、一気に実装しシンプルなテストでカバーします。ただしテストを先に書くことは忘れずに、あくまでTDDのプロセスを崩さないように進めるのが重要です。

Mocks, Stubs, and Spiesパターン

外部リソースや依存を直接テストするのではなく、モックやスタブを用いて依存を切り離します。テスト速度や独立性が向上しますが、モックを濫用するとテストが複雑化する懸念もあるため、バランスが必要です。

3. ReactでのTDD実例

ReactコンポーネントにおいてもTDDの基本的な考え方は変わりません。ここではカウンター機能の例を用いて解説します。

3.1 テストコードの例（Counter.test.tsx）

import { render, screen, fireEvent } from "@testing-library/react";
import Counter from "./Counter";

describe("Counter コンポーネントのテスト", () => {
  test("初期表示でカウントが0である", () => {
    render(<Counter />);
    expect(screen.getByText("Count: 0")).toBeInTheDocument();
  });

  test("Incrementボタンを押すと、カウントが1増える", () => {
    render(<Counter />);
    const button = screen.getByRole("button", { name: /increment/i });
    fireEvent.click(button);
    expect(screen.getByText("Count: 1")).toBeInTheDocument();
  });
});

「Count: 0」が表示されるか（初期値チェック）
「Increment」ボタンを押すとカウントが1増えるか（ボタンクリック動作チェック）

3.2 最小限の実装例（Counter.tsx）

import React, { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div className="max-w-md mx-auto p-4 m-4 bg-white rounded-2xl shadow-lg">
      <h1 className="text-xl font-bold mb-4">Simple Counter</h1>
      <p className="mb-4 text-lg">Count: {count}</p>
      <button
        className="px-4 py-2 bg-blue-500 text-white rounded-2xl hover:bg-blue-600"
        onClick={() => setCount(count + 1)}
      >
        Increment
      </button>
    </div>
  );
}

テストが「Red」になるのを確認したのち、必要最小限の実装で「Green」に。最後にリファクタリングでデザインの調整や構造の改善を行います。

4. 「Fake It」パターンを使った段階的な実装

TDDの手法の一つである「Fake It」パターンでは、最初から汎用的なロジックを組むのではなく、テストが要求する特定のケースだけを通す仮実装を行い、その後追加のテストを書いて失敗を誘発（Red）させることで、本来の汎用的な実装（Green）に導くという流れを取ります。

4.1 はじめのテスト（固定値で通る）

// sum.test.ts
import { sum } from "./sum";

describe("sum 関数のテスト", () => {
  test("2 + 2 を計算できる", () => {
    expect(sum(2, 2)).toBe(4);
  });
});

このテストだけなら、sum 関数を常に 4 を返すだけで通ってしまいます。これであえて「Fake It」し、あくまで最小限の実装に留めます。

4.2 仮実装

// sum.ts
export function sum(a: number, b: number): number {
  return 4; // 常に4を返す仮実装
}

テストを実行すると、上記の仮実装でも 2 + 2 = 4 のテストは合格（Green）します。

4.3 次のテストで本実装を強制

// sum.test.ts
import { sum } from "./sum";

describe("sum 関数のテスト", () => {
  test("2 + 2 を計算できる", () => {
    expect(sum(2, 2)).toBe(4);
  });

  test("2 + 3 を計算できる", () => {
    expect(sum(2, 3)).toBe(5);
  });
});

sum(2, 3) = 5 のテストが追加されたため、仮実装では失敗（Red）します。ここでようやく「本来の足し算」が必要だとわかるわけです。

4.4 本実装へ修正

// sum.ts
export function sum(a: number, b: number): number {
  return a + b; // 必要に応じて本実装へ
}

改めてテストを実行すると、両方のテスト（2 + 2 と 2 + 3）が通り（Green）、設計と実装が整合します。このように、追加テストで新たにRedを作り、仮実装を解除していくという流れがTDDの特徴であり、仕様を段階的に明確化するアプローチとして非常に有効です。

5. まとめ

TDDの核は「Red → Green → Refactor」の反復的サイクル

小さなステップでテスト→実装→リファクタリングを繰り返すことで、開発段階でのミスや不備を早期に発見できます。

代表的なTDDパターン

Triangulation: 複数のテストケースによって実装を汎用化
Fake It: 一時的な固定値などでテストを通し、追加テストにより本実装へ誘導
Mocks, Stubs, and Spies: 外部依存をモック化することでテストを容易にしつつ、過度なモック化は避けるバランス感覚が必要
Reactでも他の言語・フレームワーク同様、TDDの原則を適用可能

テストファーストでUIの仕様を固める
コンポーネントの入出力を小さな単位で検証し、拡張性の高いコードを目指す
「Fake It」パターンを使うメリット

大きな実装を一気に書かずに済むため、段階的に仕様を確認しながら進められる
不要なロジックを書かず、“必要に迫られたタイミング”で実装を追加するため、開発効率が向上
TDDは最初は手間がかかるように見えますが、短いサイクルでのフィードバックが得られ、バグの早期発見やリファクタリングの容易さといった大きなメリットがあります。小さな機能からぜひトライしてみて、TDDの魅力を体感してみてください。