tdd

テスト駆動開発

哲学

中核原則: テストは実装の詳細ではなく、公開インターフェースを通じて振る舞いを検証すべきです。コードは完全に変わってもかまいませんが、テストは変わるべきではありません。

良いテストは統合スタイルです。公開 API を通じて実際のコードパスを実行します。テストはシステムが 何を するかを記述し、どのように 行うかは記述しません。良いテストは仕様書のように読めます。「ユーザーは有効なカートでチェックアウトできる」は、どのような機能が存在するかを正確に示しています。こうしたテストは内部構造に関心がないため、リファクタリングにも耐えます。

悪いテストは実装に密結合しています。内部の協調オブジェクトをモックしたり、プライベートメソッドをテストしたり、外部手段 (インターフェースを使わずにデータベースを直接クエリするなど) で検証したりします。危険信号はこうです。リファクタリングしたときにテストが壊れるのに、振る舞いは変わっていない。内部関数の名前を変更してテストが失敗するなら、そのテストは振る舞いではなく実装をテストしていました。

例については tests.md を、モックのガイドラインについては mocking.md を参照してください。

アンチパターン: 水平スライス

すべてのテストを先に書き、それからすべての実装を書いてはいけません。 これは「水平スライス」であり、RED を「すべてのテストを書く」、GREEN を「すべてのコードを書く」と扱うことです。

これが生み出すのは くだらないテスト です:

• まとめて書かれたテストは 想像上の 振る舞いをテストし、実際の 振る舞いをテストしません
• ユーザー向けの振る舞いではなく、物事の 形 (データ構造、関数シグネチャ) をテストすることになります
• テストが実際の変更に鈍感になります。振る舞いが壊れても通り、振る舞いが正常でも失敗します
• 実装を理解する前にテスト構造にコミットしてしまい、ヘッドライトの届く範囲を超えて進んでしまいます

正しいアプローチ: トランサー・バレットによる垂直スライスです。1 つのテスト → 1 つの実装 → 繰り返し。各テストは前のサイクルから学んだことに応答します。コードを書いたばかりなので、どの振る舞いが重要で、それをどう検証すべきかを正確に把握しています。

WRONG (horizontal):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

RIGHT (vertical):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3
  ...

ワークフロー

1. 計画

コードベースを調査するときは、プロジェクトのドメイン用語集を使って、テスト名とインターフェースの語彙がプロジェクトの言語と一致するようにし、触れる領域の ADR を尊重してください。

コードを書く前に:

• どのようなインターフェース変更が必要かをユーザーと確認する
• どの振る舞いをテストするか (優先順位をつけて) ユーザーと確認する
• 深いモジュール (小さなインターフェース、深い実装) の機会を特定する
• テスト容易性 のためにインターフェースを設計する
• テストする振る舞いを列挙する (実装手順ではなく)
• 計画についてユーザーの承認を得る

尋ねてください: 「公開インターフェースはどのような形であるべきですか? どの振る舞いをテストするのが最も重要ですか?」

すべてをテストすることはできません。 どの振る舞いが最も重要かを、ユーザーと正確に確認してください。テストの労力は、考えられるあらゆるエッジケースではなく、クリティカルパスと複雑なロジックに集中させてください。

2. トランサー・バレット

システムについて 1 つのことを確認する 1 つのテストを書きます:

RED:   Write test for first behavior → test fails
GREEN: Write minimal code to pass → test passes

これがトランサー・バレットです。パスがエンドツーエンドで機能することを証明します。

3. インクリメンタルループ

残りの各振る舞いについて:

RED:   Write next test → fails
GREEN: Minimal code to pass → passes

ルール:

• 一度に 1 つのテスト
• 現在のテストに通るだけのコードのみ
• 将来のテストを先取りしない
• テストは観察可能な振る舞いに焦点を当て続ける

4. リファクタリング

すべてのテストが通ったら、リファクタリング候補 を探します:

• 重複を抽出する
• モジュールを深くする (複雑さをシンプルなインターフェースの背後に移す)
• 自然な箇所に SOLID 原則を適用する
• 新しいコードが既存のコードについて何を明らかにするかを考える
• リファクタリングの各ステップの後にテストを実行する

RED のままリファクタリングしないでください。 まず GREEN にしてください。

サイクルごとのチェックリスト

[ ] Test describes behavior, not implementation
[ ] Test uses public interface only
[ ] Test would survive internal refactor
[ ] Code is minimal for this test
[ ] No speculative features added