| name | tdd-workflow |
| description | 新機能の開発、バグ修正、またはリファクタリング時に使用する。ユニット、インテグレーション、E2Eテストを含め、80%以上のカバレッジを維持するテスト駆動開発を強制する。 |
| user-invocable | false |
テスト駆動開発 (TDD) ワークフロー
このガイドラインは、TDD原則に基づいた
開発の進め方（Red-Green-Refactor）を定めるもの。
言語を問わず進め方は同じ。
- テストの設計・記述の考え方（何をテストするか、
振る舞いの検証、テストの独立性、モック化の方針、
アンチパターン等）は
test-design を参照
- 言語ごとの具体的な書き方・実行コマンド
（Java の JUnit / Mockito / mvn 等）は各言語スキル
（例:
java-dev）を参照
以下は TDD の手順そのものに焦点を当てる。
アクティベーション・タイミング
- 新機能やロジックの実装時
- バグ修正や不具合の改修時
- 既存コードのリファクタリング時
- APIエンドポイントの新規作成時
- サービスやコンポーネントの新規作成時
コア・プリンシパル（主要原則）
1. 実装の前にテストを書く (Tests BEFORE Code)
常にテストを先に書き、
そのテストをパスさせるために最小限のコードを実装する。
2. カバレッジ要件
- 最低 80%以上 のカバレッジ
（Unit + Integration + E2E）
- 何をテストすべきか（正常系・異常系・境界値・
エッジケース）は
test-design を参照
3. テストの種類
ユニット / 統合 / E2E の役割分担は test-design を参照。
TDD ワークフローステップ
ステップ 1: ユーザージャーニーの記述
[役割] として、[アクション] したい。
それによって [利益] を得られる。
例:
ユーザーとして、セマンティックな市場検索を行いたい。
それによって、正確なキーワードが分からなくても
関連する市場を見つけたい。
ステップ 2: テストケースの生成
失敗するテストを先に書く。
- テストの観点（正常系・異常系・境界値・エッジケース）は
test-design を参照
- 使用フレームワークやパターンの具体的な書き方は
各言語スキル（例:
java-dev）を参照
ステップ 3: 当該テストだけ実行 (失敗することを確認)
特定のテストクラス、または特定のメソッドのみを実行して、
実装前に正しく失敗することを確認する
（実行コマンドは各言語スキルを参照）。
ステップ 4: コードの実装
テストをパスさせるための最小限のコードを書く。
ステップ 5: 再度テストを実行
対象のテストを実行し、
すべてのテストがパス（Green）することを確認する。
ステップ 6: リファクタリング
テストがパスした状態を維持しながら、
コードの品質を向上させる。
ステップ 7: カバレッジの確認
カバレッジを計測し、要件（80%以上）を満たすか確認する。
計測ツールや手順は各言語スキルを参照。
継続的テスト (Continuous Testing)
成功のメトリクス
test-design の成功メトリクスに加え、本ワークフローでは
以下を満たすこと。
- 80%+ コードカバレッジ達成
- Red-Green-Refactor のサイクルを踏んでいること
忘れないでください: テストはオプションではない。
自信を持ったリファクタリング、迅速な開発、
そして本番環境の信頼性を支えるための「命綱」である。
