TDD Architect

t-wada（和田卓人）氏のTDD哲学に基づいたテスト駆動開発ガイド。

TDDサイクル

┌─────────────────────────────────────────┐
│                                         │
│   ┌───────┐    ┌───────┐    ┌────────┐  │
│   │  RED  │ →  │ GREEN │ →  │REFACTOR│  │
│   └───────┘    └───────┘    └────────┘  │
│       ↑                          │      │
│       └──────────────────────────┘      │
│                                         │
└─────────────────────────────────────────┘

Phase 1: RED - 失敗するテストを書く

目的: 実装すべき振る舞いを明確にする

1. •一つの振る舞いだけをテストする
2. •テスト名で意図を明確に表現する
3. •Arrange-Act-Assert構造で書く
4. •テストを実行し、失敗することを確認する

// 命名規則: "should [期待する振る舞い] when [条件]"
it('should return sum when adding two positive numbers')
it('should throw error when input is negative')

Phase 2: GREEN - 最小限のコードで通す

目的: テストを通す最もシンプルなコードを書く

1. •過剰な実装をしない（YAGNI）
2. •ハードコードでも良い（後でリファクタする）
3. •テストが通ったら即座に次へ進む
4. •設計の美しさは後回し

Phase 3: REFACTOR - コードを整理する

目的: テストを Green に保ちながらコードを改善する

1. •テストは変更しない（振る舞いは変えない）
2. •重複を除去する
3. •命名を改善する
4. •小さなステップで進める
5. •各ステップ後にテストが通ることを確認

テスト構造 (Arrange-Act-Assert)

// Arrange (Given) - 準備: テスト対象とデータを用意
const calculator = new Calculator();
const a = 1, b = 2;

// Act (When) - 実行: テスト対象の操作を1つだけ実行
const result = calculator.add(a, b);

// Assert (Then) - 検証: 期待する結果を検証
expect(result).toBe(3);

ワークフロー判断

新機能の実装

1. •最も単純なケースのテストを書く（RED）
2. •通す（GREEN）
3. •次のケースのテストを追加（RED）
4. •通す（GREEN）
5. •リファクタリング（REFACTOR）
6. •繰り返す

バグ修正

1. •バグを再現するテストを書く（RED）
2. •テストが失敗することを確認
3. •バグを修正（GREEN）
4. •必要ならリファクタリング（REFACTOR）

リファクタリング

1. •既存のテストが全て通ることを確認
2. •小さな変更を加える
3. •テストを実行して通ることを確認
4. •繰り返す
5. •リファクタリング中は新しいテストを追加しない

避けるべきアンチパターン

• •テストなしでコミット: 必ずテストを先に書く
• •複数のことを1テストで検証: 1テスト1アサーション原則
• •実装の詳細をテスト: 振る舞い（入力→出力）をテストする
• •テスト間の依存: 各テストは独立して実行可能に
• •過剰なモック: 本物を使えるなら本物を使う

詳細リファレンス

より詳細なTDD原則については references/tdd-principles.md を参照。