TDD Skill

テスト駆動開発（TDD）のワークフローを厳格にガイドするスキル。

superpowers:test-driven-development の鉄の法則に従いつつ、以下を追加で提供する：

•VERIFY ループ（型チェック・リント・テストの自動検証、最大3回）
•コミットルール（test/feat/refactor の分離）
•t_wada のテスト原則との統合

詳細なテスト原則は @~/.claude/rules/testing.md を参照。

When to Use This Skill

Trigger when:

•/TDD コマンドを実行
•「TDDで開発して」「テスト駆動で」と依頼
•@~/.claude/rules/implementation.md のタスク実行時（Step 2 で自動的に呼び出される）
•superpowers:subagent-driven-development 内で個別タスクをTDDで実装する場合

核心原則

鉄の法則（superpowers:test-driven-development と共通）

失敗するテストなしに、プロダクションコードを書かない

TDDの目的（t_wada）

信頼性の高い実行結果に短時間で到達する状態を保つことで、開発者に根拠ある自信を与え、ソフトウェアの成長を持続可能にすること

Kent Beck の TDD 5ステップ

•テストリストを書く - 網羅したいシナリオをリストアップ
•1つ選んでテストを書く - 具体的で実行可能なテストコード、失敗を確認
•テストを通す - 最小限の実装で成功させる
•リファクタリング - 設計を改善（テストは成功を維持）
•繰り返す - テストリストが空になるまで

コンテキスト汚染を防ぐ

"テストが実装後に書かれると、テストは実装に合わせて書かれる。テストはコードが何をするかを証明するだけ — 完璧なトートロジー（同語反復）である"

対策: テストは要件に基づいて書く、実装を見ない

実装フロー

Phase 0: 終了条件の明確化

計画のタスク定義（@~/.claude/rules/plan-mode.md Phase 3 のフォーマット）がある場合、そこから終了条件を導出する。ない場合は以下を自分で定義する。

markdown

## 終了条件

### 実装する機能
（1文で説明。計画のタスク名に対応）

### I/O シグネチャ
（計画で定義済みの型情報。なければここで定義）

### 成功の定義（全て満たしたら完了）
- [ ] 全テストケースがパス
- [ ] カバレッジ80%以上
- [ ] 品質検証がパス（`superpowers:verification-before-completion` 参照）

### スコープ外（今回やらないこと）
- （明示的に除外する機能）

Phase 1: テスト設計（実装を見ない）

計画のタスク定義に受入条件がある場合、それをテストリストの出発点とする。受入条件の WHEN...THEN を具体的なテストケースに変換し、不足があれば追加する。

1.1 ユーザージャーニーの作成

markdown

### シナリオ1: 新規ユーザー登録
As a 新規ユーザー
I want to メールアドレスで登録
So that サービスを利用できる

1.2 テストケースの列挙

markdown

### 正常系（ユーザーが見える動作）
- [ ] 有効なメールアドレスでtrueを返すこと

### 異常系（エッジケース）
- [ ] @がない場合falseを返すこと
- [ ] 空文字でfalseを返すこと

重要: 実装の詳細ではなく、ユーザーが見える動作をテストする

1.3 テストファイルの準備

テストリストをもとに、空の describe ブロックだけ作成する。 it.skip でテストを先に全部コード化しない — テストは1つずつREDフェーズで書く。

Phase 2: RED-GREEN-REFACTOR（1テストずつ）

2.1 RED: テストを書く

テストを書き、実行して失敗を確認する（必須）。

2.2 GREEN: 最小限の実装

最小限のコードでテストを通す。実行して成功を確認する（必須）。

2.3 VERIFY: 自動検証ループ（GREEN後に必須）

GREEN完了後、自動的に検証を実行する：

code

GREEN成功 → 検証実行 → 失敗 → 修正 → 検証 → ...（最大3回）
                         ↓
                    成功 → REFACTOR へ
                         ↓
                    3回失敗 → [TDD:BLOCKED] ユーザーに確認

検証内容:

•型チェック（tsc --noEmit など）
•リント（eslint など）
•関連テストの実行

3回失敗時:

code

[TDD:BLOCKED]
検証が3回連続で失敗しました。

## 失敗履歴
1. lint: unused variable
2. type: Type 'string' is not assignable to 'Email'
3. test: Expected true, received false

ユーザーの判断を求めます：
- 続行（手動で修正を指示）
- スキップ（このテストを後回し）
- 中断（計画を見直し）

2.4 REFACTOR: リファクタ

•Task ツールで subagent_type: "code-simplifier" を呼び出し、変更したコードを簡素化
•重複の除去、可読性の向上
•テストは変更しない（成功を維持）
•code-simplifier 適用後、テストを再実行して成功を確認

2.5 コミット

各サイクル完了後にコミット。

Phase 3: 繰り返し

テストリストから次のケースを選び、Phase 2 を繰り返す。

Phase 4: 最終検証

superpowers:verification-before-completion に従い、ビルド・型・リント・全テストを実行して証拠を示す。

コミットルール

•test - テストの追加（REDフェーズ）
•feat - 機能実装（GREENフェーズ）
•refactor - リファクタ（REFACTORフェーズ）

エラー時の対応

テストが最初から成功する（REDで失敗しない）

既存の実装がテストを満たしている場合:

•テストを修正し、未実装の振る舞いをテストする

実装を先に書いてしまった場合:

•実装を削除し、テストから書き直す — 参考にすることも禁止