tdd-workflow

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)

• TBD

成功のメトリクス

test-design の成功メトリクスに加え、本ワークフローでは 以下を満たすこと。

• 80%+ コードカバレッジ達成
• Red-Green-Refactor のサイクルを踏んでいること

---

忘れないでください: テストはオプションではない。 自信を持ったリファクタリング、迅速な開発、 そして本番環境の信頼性を支えるための「命綱」である。