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 フェーズの原則

書くべきもの

焦点	例
振る舞い	「二つの数値を加算するべき」
エッジケース	「空の入力を処理するべき」
エラー状態	「不正なデータに対して例外を投げるべき」

RED フェーズのルール

• テストはまず失敗しなければならない
• テスト名は期待される振る舞いを記述する
• テストごとに一つのアサーション（理想的には）

---

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 フェーズを飛ばす	まずテストが失敗するのを見る
後からテストを書く	前にテストを書く
最初から過剰に設計する	シンプルに保つ
複数のアサーション	テストごとに一つの振る舞い
実装をテストする	振る舞いをテストする

---

10. AI を活用した TDD

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

エージェント	役割
エージェント A	失敗するテストを書く（RED）
エージェント B	成功させるために実装する（GREEN）
エージェント C	最適化する（REFACTOR）

---

覚えておいてください: テストは仕様です。テストが書けないなら、その要件を理解していません。

使用するタイミング

このスキルは、概要に記載されたワークフローまたはアクションを実行する場合に適用できます。

制限事項

• このスキルは、タスクが上記の範囲に明確に一致する場合にのみ使用してください。
• 出力を環境固有の検証、テスト、または専門家によるレビューの代替として扱わないでください。
• 必要な入力、権限、安全境界、または成功基準が欠けている場合は、停止して確認を求めてください。