TDD ワークフロー

テストを先に書き、コードは後で。

---

1. TDD サイクル

🔴 RED → 失敗するテストを書く
    ↓
🟢 GREEN → テストを通すための最小限のコードを書く
    ↓
🔵 REFACTOR → コード品質を改善する
    ↓
   繰り返す...

---

2. TDD の三原則

1. 失敗するテストを成功させるためにのみ、プロダクションコードを書く
2. 失敗を示すのに必要な分だけテストを書く
3. テストを成功させるのに必要な分だけコードを書く

---

3. RED フェーズの原則

何を書くか

焦点	例
動作	「2つの数を足すべき」
エッジケース	「空の入力を処理すべき」
エラー状態	「無効なデータで例外を投げるべき」

RED フェーズのルール

• テストは最初に失敗すること
• テスト名は期待される動作を説明する
• 理想的には1つのテストに1つのアサーション

---

4. GREEN フェーズの原則

最小限のコード

原則	意味
YAGNI	You Aren't Gonna Need It (今は必要ない)
最もシンプルなもの	テストを通すための最小限を書く
最適化なし	動作させるだけでいい

GREEN フェーズのルール

• 不要なコードを書かない
• まだ最適化しない
• テストを通す、それ以上のことはしない

---

5. REFACTOR フェーズの原則

何を改善するか

領域	アクション
重複	共通コードを抽出する
命名	意図を明確にする
構造	組織を改善する
複雑さ	ロジックを簡潔にする

REFACTOR のルール

• すべてのテストは緑を保つ
• 小さな段階的変更
• リファクタ後にコミットする

---

6. AAA パターン

すべてのテストは以下に従う:

ステップ	目的
Arrange	テストデータを準備する
Act	テスト対象のコードを実行する
Assert	期待される結果を検証する

---

7. TDD を使うべき時

シナリオ	TDD の価値
新機能	高
バグ修正	高 (最初にテストを書く)
複雑なロジック	高
探索的開発	低 (スパイク後に TDD)
UI レイアウト	低

---

8. テストの優先順位

優先度	テストタイプ
1	正常系
2	エラーケース
3	エッジケース
4	パフォーマンス

---

9. アンチパターン

❌ しないこと	✅ すること
RED フェーズをスキップ	テスト失敗を最初に見る
テストを後で書く	テストを先に書く
最初から過設計	シンプルに保つ
複数のアサーション	1つの動作に1つのテスト
実装をテストする	動作をテストする

---

10. AI 拡張 TDD

マルチエージェントパターン

エージェント	役割
エージェント A	失敗するテストを書く (RED)
エージェント B	テストを通すコードを実装する (GREEN)
エージェント C	最適化する (REFACTOR)

---

覚えておくこと: テストが仕様書です。テストが書けなければ、要件を理解していません。