TDD ワークフローを Claude Code で実践する

症状・対象

実装後にテストを足したため、テストが一度も失敗せず、回帰を本当に検出できるか分からない場合が対象です。Claude Code 単体でも進められますが、Superpowers の test-driven-development または ECC の /tdd を使うと RED → GREEN → REFACTOR の順序を明示できます。

最短解決

既存のテストランナーと、対象テストだけを実行するコマンドを確認します。
一つの振る舞いを表すテストを書き、期待した理由で失敗することを確認します。
そのテストを通す最小の実装だけを追加します。
全テストを成功させたまま重複や命名を整理します。
修正を一時的に戻し、テストが再び失敗することまで確認します。

コピペ例

Superpowers が入っている場合はスキル名、ECC が入っている場合は /tdd を明示して、次の依頼を使います。

test-driven-development スキルを使い、次の不具合を RED → GREEN → REFACTOR で直して。

症状:
- メールアドレスの前後に空白があるとログインに失敗する

完了条件:
- 前後の空白だけを除去する
- 大文字小文字を勝手に変更しない
- 空文字と空白だけの入力は既存のバリデーションに渡す

進め方:
1. package.json と既存テストから対象テストの実行コマンドを特定
2. 失敗する回帰テストを一つ追加
3. その失敗結果を示してから最小実装
4. 対象テスト、全テスト、型チェックを実行
5. 各段階のコマンドと結果を報告

禁止:
- RED を確認する前の本番コード編集
- テストを通すためだけの本番 API 追加

ECC を明示的に起動する場合は、先に次を実行してから同じ要件を渡します。

> /tdd

期待結果

最初に新しいテストが既存実装で失敗し、次に最小実装で成功します。REFACTOR 後も対象テストと全体テストが成功し、報告には RED と GREEN の実行コマンド・終了結果が分けて残ります。

検証

RED が構文エラーや環境不足ではなく、期待する振る舞いの不一致で失敗したか確認します。
実装を一時的に元へ戻すか変異させ、新しいテストが失敗することを確認します。
対象テストだけでなく全テストと型チェックを実行します。
モックの呼び出し回数だけでなく、利用者が観測する結果を検証します。

落とし穴

先に実装してからテストを書くと、現在の実装を追認するテストになりやすくなります。
一度も失敗していないテストは、回帰検出能力を確認できていません。
カバレッジ率だけではアサーションの妥当性を判断できません。
テストが難しいときに本番コードへテスト専用 API を足す前に、責務や依存境界を見直します。
Superpowers と ECC の TDD 進行を同時に自動起動すると指示が重複します。今回の進行役を一つ選びます。

次の一手

設計自体が曖昧なら Superpowers の Brainstorming、最終ゲートを標準化するなら ECC のハーネスエンジニアリングへ進みます。