tdd-workflow

TDD ワークフロー

まずテストを書き、次にコードを書く。

---

1. TDD のサイクル

🔴 RED → Write failing test
    ↓
🟢 GREEN → Write minimal code to pass
    ↓
🔵 REFACTOR → Improve code quality
    ↓
   Repeat...

---

2. TDD の三つの法則

1. 失敗しているテストを通すためにだけ、プロダクションコードを書く
2. 失敗を示すのに十分なだけテストを書く
3. テストを通すのに十分なだけコードを書く

---

3. RED フェーズの原則

何を書くか

観点	例
振る舞い	「2 つの数値を加算できること」
エッジケース	「空の入力を扱えること」
エラー状態	「不正なデータに対して例外を投げること」

RED フェーズのルール

• テストは最初に失敗しなければならない
• テスト名は期待される振る舞いを説明する
• 1 テストにつきアサーションは 1 つ（可能な限り）

---

4. GREEN フェーズの原則

最小限のコード

原則	意味
YAGNI	必要になるとは限らない機能は作らない
最も単純な方法	テストを通す最小限のものを書く
最適化しない	まずは動くようにする

GREEN フェーズのルール

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

---

5. REFACTOR フェーズの原則

改善対象

領域	対応
重複	共通コードを抽出する
命名	意図が明確になるようにする
構造	構成を改善する
複雑さ	ロジックを単純化する

REFACTOR のルール

• すべてのテストがグリーンのままであること
• 小さく段階的に変更する
• リファクタリングのたびにコミットする

---

6. AAA パターン

すべてのテストは次に従います：

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

---

7. TDD を使うべきとき

シナリオ	TDD の価値
新機能	高
バグ修正	高（先にテストを書く）
複雑なロジック	高
探索的な作業	低（スパイクを行い、その後 TDD）
UI レイアウト	低

---

8. テストの優先順位

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

---

9. アンチパターン

❌ やめること	✅ 推奨
RED フェーズを飛ばす	最初にテストが失敗するのを確認する
後からテストを書く	先にテストを書く
最初から過剰設計する	シンプルに保つ
1 テストに複数のアサーション	1 テストにつき 1 つの振る舞い
実装をテストする	振る舞いをテストする

---

10. AI を活用した TDD

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

エージェント	役割
エージェント A	失敗するテストを書く（RED）
エージェント B	テストを通すように実装する（GREEN）
エージェント C	最適化する（REFACTOR）

---

覚えておくこと: テストは仕様である。テストが書けないなら、要件を理解していないということです。