test-driven-development

テスト駆動開発

TDD のサイクル

1. レッド：失敗するテストを書く
2. グリーン：テストに合格する最小限のコードを書く
3. リファクタリング：テストがグリーンの状態を保ちながらコードを改善する

ワークフロー

• テストを書く：望ましい動作を記述するテストを書く
• テストを実行する：失敗することを確認する（レッド）
• 実装する：合格するための最小限のコードを書く
• テストを実行する：合格することを確認する（グリーン）
• リファクタリングする：テストがグリーンの状態を保ちながら整理する
• 繰り返す：次のテストケースに進む

TDD の例

ステップ 1：レッド — 失敗するテストを書く

describe("Calculator", () => {
  test("adds two numbers", () => {
    const calc = new Calculator();
    expect(calc.add(2, 3)).toBe(5);
  });
});

// Run: FAIL - Calculator is not defined

ステップ 2：グリーン — 最小限の実装

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

// Run: PASS

ステップ 3：リファクタリング（必要な場合）

コードはすでに整理されているため、次のテストに進みます。

ステップ 4：次のテスト

test("subtracts two numbers", () => {
  const calc = new Calculator();
  expect(calc.subtract(5, 3)).toBe(2);
});

// Run: FAIL - subtract is not defined

TDD のメリット

• 設計へのフィードバック：テストにより設計上の問題を早期に発見できます
• ドキュメント：テストによって期待される動作を記録できます
• 自信：テストというセーフティネットがあるため、安心してリファクタリングできます
• 集中：一度に 1 つの動作に取り組めます

TDD のヒント

1. シンプルに始める：最もシンプルなテストケースから始めます
2. アサーションは 1 つ：各テストでは 1 つの動作を検証します
3. 説明的な名前を付ける：テスト名はドキュメントになります
4. テストにロジックを入れない：テストは明快であるべきです
5. 素早くフィードバックを得る：テストは数ミリ秒で実行できるようにします

TDD を使う場面

• 要件が明確な新機能
• バグ修正（まず失敗するテストを書く）
• 複雑なビジネスロジック
• API コントラクトの開発

TDD があまり役立たない場面

• 探索的なコード／プロトタイプコード
• UI レイアウトの変更
• シンプルな CRUD 操作