tdd-workflow

TDD ワークフロー

規律ある red → green → refactor のループです。一度に扱うのは失敗するテスト一つだけです。テストを通すための最小限のコードを書き、すべてのテストが通る状態でリファクタリングします。これは方法論に関するスキルです。ループに厳密に従い、まとめて進めないでください。

使用するタイミング

動作をアサーションで表現できる場合に使用します。ビジネスロジック、パーサー、API、アルゴリズム、バグ修正（まず失敗するテストで再現する）などが対象です。使い捨ての試作、純粋な UI レイアウト、保守する予定のない探索的なプロトタイプには使用しません。

ループ

RED — 失敗するテストを一つ書く

• 仕様が定まっていない動作のうち、最も小さいものを選びます。
• それを検証するテストを一つ書き、実行します。正しい理由で失敗すること（インポートエラーや構文エラーではなく、アサーションの失敗）を確認します。
• すぐに成功するテストや、タイプミスが原因で失敗するテストは red ではありません。修正して再実行します。

GREEN — テストを通すための最小限のコードを書く

• そのテストを通すために必要な最小限のコードを書きます。この段階ではハードコードも許容されます。
• 新しいテストだけでなく、テストスイート全体を実行します。すべて通れば green です。
• 「ついでに」未テストのコードを追加しないでください。追加したい場合はテストが必要です。RED に戻ってください。

REFACTOR — green の状態で改善する

• 重複を取り除き、名前を分かりやすくし、構造を簡潔にします。
• 変更のたびにテストスイート全体を再実行します。失敗があれば、先に進んでデバッグせず、リファクタリングを元に戻します。
• ここでは動作を変更しません。新しい動作は新しい RED です。

機能のすべての動作がテストで網羅されるまで繰り返します。

セットアップ

プロジェクトで既に使われているテストランナーを検出します。新しいものを導入しないでください。

# JS/TS:  npx vitest run   |  npx jest
# Python: pytest -q
# Go:     go test ./...
# Rust:   cargo test

フレームワークがない場合は、作業を始める前にどれを追加するか確認し、エコシステムの標準に合わせます。

バグ修正モード

1. RED：バグを再現して失敗するテストを書きます。
2. GREEN：テストが通り、ほかに何も壊れなくなるまで修正します。
3. 再現テストは回帰を防ぐために残します。

バグが存在したことを証明する失敗テストなしに、バグを修正してはいけません。

テストの品質

• 1 テストにつき 1 つの動作を検証し、テスト名でその動作を示します。
• 内部呼び出しではなく、観測可能な結果をアサートします。ただし、やり取りそのものが契約である場合を除きます。
• エッジケースはそれぞれ独立した RED として扱います。空の入力、境界値、不正な入力、非同期処理の失敗、並行処理などが対象です。
• コードを壊しても失敗しないテストは何も検証していません。削除するか修正してください。

アンチパターン

• 先に実装を書き、それに合うテストを書く（それは TDD ではありません）。
• テストを 10 個書いてから実装する（設計に関するフィードバックを得られなくなります）。
• 「失敗することを確認する」手順を省略する。
• リファクタリングと動作の追加を同じ手順で行う。
• 実際のコードが壊れていてもテストが通るほど過剰にモックを使う。

完了条件

すべての動作について、先に失敗するテストがあり、そのテストが通っていること、テストスイート全体が成功していること、未テストの本番コードがないこと、そしてバグ修正テストが回帰防止のために保持されていること。