test-driven-development

テスト駆動開発

次の振る舞いを示す失敗するテストを1つ書き、それを通す最小限のコードを書いてから、テストがすべて通っている状態でリファクタリングします。すべての本番コードの変更は、その必要性を示すテストから始めます。これは各垂直スライスで守るべき規律です。重要なのはフレームワークの構文ではなく、テストを書くタイミングと理由です。

探索的なプロトタイピング、設定のみの変更（環境変数、機能フラグ）、ビジュアルやCSSのみの調整、保守を予定していない単発のスクリプトでは省略します。

クイックリファレンス — TDD サイクル

フェーズ	アクション	ルール
RED	適切な理由で失敗するテストを1つ書く	失敗するテストなしで本番コードを書かない
GREEN	テストを通す最もシンプルなコードを書く	早まって汎用化したくなる気持ちを抑える
REFACTOR	すべてのテストを通したまま構造を改善する	振る舞いと構造を同時に変更しない

クイックリファレンス — 原則

原則	実践
一度に1つのテスト	次のテストを書く前に、レッド・グリーン・リファクタリングのサイクルを完了する
実装より振る舞い	コードの動作をテストし、動作の仕方はテストしない。出力と副作用を検証する
垂直スライス	レイヤーごとではなく、エンドツーエンドの振る舞いを一度に1つずつTDDする
境界でモックする	I/O、ネットワーク、ファイルシステム、クロックをモックする。内部の協調相手はモックしない
深いモジュール	内部が豊かな小さなインターフェースを設計する。より少ないテストで多くの振る舞いを網羅する
グリーンのときだけリファクタリング	構造に手を加える前にすべてのテストを通す。レッドの状態でのリファクタリングは新たなバグを隠す
テストを通して設計する	最初のテストがAPI設計の決定そのもの。テストが書きにくければ、インターフェースも扱いにくい
すべてのバグに失敗するテスト	修正コードを書く前に、失敗するテストでバグを再現する

コーディング前の計画

手順	アクション	成果物
1	振る舞いを特定する	機能が示すべき、観測可能な振る舞いの一覧
2	依存関係順に並べる	各テストが、それまでに合格したテストを基に進む順序
3	インターフェースを設計する	関数シグネチャ、パラメーター型、戻り値の型
4	モックの境界を特定する	テストダブルが必要な外部依存関係

よくある間違い

間違い	正しいパターン
すべてのテストを最初に書く	テストは一度に1つずつ書きます。次に進む前にサイクルを完了させます
プライベートメソッドをテストする	パブリックインターフェースを通じてテストします。プライベートメソッドは実装の詳細です
内部の協調オブジェクトをモックする	I/O の境界でのみモックし、自分のコードは信頼します
失敗するテストを書く前にコードを書く	まず RED にします。失敗するテストによって、その動作がまだ実装されていないことを確認できます
テストが失敗している間にリファクタリングする	まず GREEN にします。その後、自信を持ってリファクタリングします
呼び出し順序に依存するテスト	内部メソッドが呼び出されたかどうかではなく、出力と状態を検証します
リファクタリングの段階を省略する	GREEN になっても完了ではありません。次に進む前に重複や命名を整理します
期待値をハードコードする	三角測量を使います。2つ目のテストケースを追加して、汎用的な解決策が必要になるようにします
1つの機能につき巨大なテストを1つ書く	動作ごとにテストを1つ書きます。小さく、焦点が絞られ、単独で意味を持つテストにします

委任

• スライスへの分解：tracer-bullets スキルが利用できる場合は、各スライス内で TDD を適用する前に、機能を垂直スライスに分解するために使用します
• テストフレームワークの構文：フレームワーク固有のパターンは、vitest-testing、e2e-testing、または api-testing スキルに委任します
• 機能の計画：plan-first-development スキルが利用できる場合は、TDD サイクルに入る前の事前計画に使用します
• 個々の TDD サイクル：コンテキストを集中させるため、各 red-green-refactor サイクルを Task サブエージェントに委任します

参考資料

• テストの品質 — 良いテストと悪いテスト、何をテストするか、命名、三角測量、リファクタリングの兆候
• モックの境界 — 境界ルール、テストダブル、依存性注入、アンチパターン
• テスト容易性を考慮した設計 — 深いモジュール、インターフェース優先の設計、純粋関数、計算と I/O