テスト駆動開発 (TDD)

概要

テストを最初に書く。失敗するのを見る。最小限のコードを書いて合格させる。

核となる原則: テストが失敗するのを見なければ、そのテストが正しいことをテストしているかどうか分からない。

ルールの文字通りに違反することは、ルールの精神に違反することである。

使うタイミング

常に:

• 新機能
• バグ修正
• リファクタリング
• 動作の変更

例外 (人間のパートナーに相談):

• 一時的なプロトタイプ
• 生成されたコード
• 設定ファイル

「今回だけ TDD をスキップしよう」と考えている? 止めなさい。それは言い訳だ。

鉄の法則

テストが失敗することなく、本番コードを書いてはいけない

テストより先にコードを書いた? 削除しろ。最初からやり直す。

例外はない:

• 「参考」として保つな
• テストを書きながら「適応」させるな
• 見るな
• 削除とは削除のことだ

テストから新規で実装する。以上。

Red-Green-Refactor

digraph tdd_cycle {
    rankdir=LR;
    red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"];
    verify_red [label="Verify fails\ncorrectly", shape=diamond];
    green [label="GREEN\nMinimal code", shape=box, style=filled, fillcolor="#ccffcc"];
    verify_green [label="Verify passes\nAll green", shape=diamond];
    refactor [label="REFACTOR\nClean up", shape=box, style=filled, fillcolor="#ccccff"];
    next [label="Next", shape=ellipse];

    red -> verify_red;
    verify_red -> green [label="yes"];
    verify_red -> red [label="wrong\nfailure"];
    green -> verify_green;
    verify_green -> refactor [label="yes"];
    verify_green -> green [label="no"];
    refactor -> verify_green [label="stay\ngreen"];
    verify_green -> next;
    next -> red;
}

RED - テストが失敗することを確認

何が起こるべきかを示す最小限のテストを 1 つ書く。

<Good> ```typescript test('retries failed operations 3 times', async () => { let attempts = 0; const operation = () => { attempts++; if (attempts < 3) throw new Error('fail'); return 'success'; };

const result = await retryOperation(operation);

expect(result).toBe('success'); expect(attempts).toBe(3); });

明確な名前、実際の動作をテスト、1 つのこと
</Good>

<Bad>
```typescript
test('retry works', async () => {
  const mock = jest.fn()
    .mockRejectedValueOnce(new Error())
    .mockRejectedValueOnce(new Error())
    .mockResolvedValueOnce('success');
  await retryOperation(mock);
  expect(mock).toHaveBeenCalledTimes(3);
});

曖昧な名前、モックをテスト、コードではない </Bad>

要件:

• 1 つの動作
• 明確な名前
• 実際のコード (不可避な場合を除きモックなし)

RED を確認 - テストが失敗するのを見る

必須。スキップするな。

npm test path/to/test.test.ts

以下を確認:

• テストが失敗する (エラーではなく)
• 失敗メッセージが期待通り
• 機能がないため失敗する (タイポではなく)

テストが合格した? 既存の動作をテストしている。テストを修正する。

テストがエラーになった? エラーを修正して、正しく失敗するまで再実行する。

GREEN - 最小限のコード

テストを合格させるための最も単純なコードを書く。

<Good> ```typescript async function retryOperation<T>(fn: () => Promise<T>): Promise<T> { for (let i = 0; i < 3; i++) { try { return await fn(); } catch (e) { if (i === 2) throw e; } } throw new Error('unreachable'); } ``` 合格させるのに十分なだけ </Good> <Bad> ```typescript async function retryOperation<T>( fn: () => Promise<T>, options?: { maxRetries?: number; backoff?: 'linear' | 'exponential'; onRetry?: (attempt: number) => void; } ): Promise<T> { // YAGNI } ``` 過度に設計されている </Bad>

機能を追加したり、他のコードをリファクタしたり、テストを超えて「改善」してはいけない。

GREEN を確認 - テストが合格するのを見る

必須。

npm test path/to/test.test.ts

以下を確認:

• テストが合格する
• 他のテストも合格する
• 出力が清潔 (エラーなし、警告なし)

テストが失敗した? テストではなくコードを修正する。

他のテストが失敗した? 今すぐ修正する。

REFACTOR - クリーンアップ

GREEN の後のみ:

• 重複を削除
• 名前を改善
• ヘルパーを抽出

テストを GREEN に保つ。動作を追加しない。

繰り返す

次の機能のための次のテストが失敗します。

良いテスト

品質	良い	悪い
最小限	1 つのこと。名前に「and」? 分ける。	test('validates email and domain and whitespace')
明確	名前が動作を説明する	test('test1')
意図を示す	望まれる API を実証する	コードが何をすべきかを不明瞭にする

順序が重要な理由

「後でテストを書いて動作を確認しよう」

コードの後に書かれたテストは即座に合格する。合格は何も証明しない:

• 間違ったことをテストしているかもしれない
• 動作ではなく実装をテストしているかもしれない
• 忘れた境界ケースを逃すかもしれない
• バグを捕捉するのを見たことがない

テスト優先は、テストが実際に何かをテストしていることを証明するために、テストが失敗するのを見ることを強制する。

「すべての境界ケースを手動でテスト済み」

手動テストはアドホック。すべてをテストしたと思っているが:

• 何をテストしたかの記録がない
• コードが変更された時に再実行できない
• プレッシャーの下で簡単にケースを忘れる
• 「試したときに動いた」≠ 包括的

自動テストは体系的。毎回同じ方法で実行される。

「X 時間の作業を削除するのは浪費」

サンク・コスト・フォールシー。その時間はすでに過去のもの。今のあなたの選択:

• 削除して TDD で書き直す (さらに X 時間、高い信頼)
• 保って後でテストを追加 (30 分、低い信頼、バグの可能性)

「浪費」は信頼できないコードを保つことだ。実際のテストなしの動作するコードは技術的負債。

「TDD は独断的で、実利的であることは適応を意味する」

TDD は実利的:

• コミット前にバグを見つける (コミット後のデバッグより速い)
• リグレッションを防ぐ (テストが瞬時に破損を捕捉)
• 動作を文書化 (テストはコードの使い方を示す)
• リファクタリングを可能にする (テストが破損を捕捉するため自由に変更)

「実利的」なショートカット = 本番環境でのデバッグ = 遅い。

「テスト後は同じ目標を達成する - それは儀式ではなく精神だ」

いいえ。テスト後は「これは何をするか?」に答える テスト優先は「これは何をすべきか?」に答える

テスト後は実装によってバイアスがかかる。構築したものをテストする、必要とされるものではない。覚えている境界ケースを確認し、発見したケースではない。

テスト優先は実装前に境界ケースの発見を強制する。テスト後は覚えているすべてを確認 (覚えていない)。

30 分のテスト後 ≠ TDD。カバレッジを得て、テストが動作することの証明を失う。

よくある言い訳

言い訳	現実
「テストするには単純すぎる」	単純なコードは壊れる。テストは 30 秒。
「後でテストする」	テストの合格は何も証明しない。
「テスト後は同じ目標を達成する」	テスト後 = 「これは何をするか?」 テスト優先 = 「これは何をすべきか?」
「すでに手動でテスト済み」	アドホック ≠ 体系的。記録がない、再実行できない。
「X 時間の削除は浪費」	サンク・コスト・フォールシー。検証されないコードの保持は技術的負債。
「参考として保持して、テストを優先に書く」	適応させる。それはテスト後だ。削除とは削除のことだ。
「最初に探索が必要」	いい。探索を破棄して、TDD で開始する。
「テストが難しい = 設計が不明確」	テストを聞く。テストが難しい = 使いづらい。
「TDD は遅くなる」	TDD はデバッグより速い。実利的 = テスト優先。
「手動テストが速い」	手動は境界ケースを証明しない。毎回の変更を再テストする。
「既存コードにテストがない」	改善している。既存コードにテストを追加する。

赤旗 - 停止して最初からやり直す

• テストの前のコード
• 実装後のテスト
• テストが即座に合格
• テストが失敗した理由を説明できない
• 後で追加されたテスト
• 「今回だけ」を正当化する
• 「すでに手動でテスト済み」
• 「テスト後は同じ目的を達成する」
• 「精神の問題で儀式ではない」
• 「参考として保持」または「既存コードを適応」
• 「すでに X 時間費やした、削除は浪費」
• 「TDD は独断的、私は実利的」
• 「これは異なる理由は...」

これらすべての意味: コードを削除。TDD で最初からやり直す。

例: バグ修正

バグ: 空のメールが受け入れられる

RED

test('rejects empty email', async () => {
  const result = await submitForm({ email: '' });
  expect(result.error).toBe('Email required');
});

RED を確認

$ npm test
FAIL: expected 'Email required', got undefined

GREEN

function submitForm(data: FormData) {
  if (!data.email?.trim()) {
    return { error: 'Email required' };
  }
  // ...
}

GREEN を確認

$ npm test
PASS

REFACTOR 複数のフィールドに必要な場合は検証を抽出する。

検証チェックリスト

作業完了前に:

• 新しい関数/メソッドにはテストがある
• 実装する前に各テストが失敗するのを見た
• 各テストが期待される理由で失敗した (タイポではなく機能がない)
• 各テストを合格させるための最小限のコードを書いた
• すべてのテストが合格する
• 出力が清潔 (エラーなし、警告なし)
• テストは実際のコードを使用 (不可避な場合を除きモックなし)
• 境界ケースとエラーがカバーされている

すべてのボックスをチェックできない? TDD をスキップした。最初からやり直す。

詰まった時

問題	解決策
テスト方法が分からない	望まれた API を書く。最初にアサーションを書く。人間のパートナーに相談する。
テストが複雑すぎる	設計が複雑すぎる。インターフェースを簡素化。
すべてをモックする必要がある	コードが密結合。依存性注入を使用。
テストセットアップが巨大	ヘルパーを抽出。まだ複雑? 設計を簡素化。

デバッグ統合

バグが見つかった? それを再現するテストが失敗します。TDD サイクルに従う。テストは修正を証明し、リグレッションを防ぐ。

テストなしでバグを修正しない。

テスト・アンチパターン

モックやテストユーティリティを追加する場合は、@testing-anti-patterns.md を読んで一般的な落とし穴を回避する:

• モックの動作ではなく実際の動作をテスト
• テスト専用メソッドを本番クラスに追加
• 依存関係を理解せずにモック

最終ルール

本番コード → テストが存在し最初に失敗した
それ以外 → TDD ではない

人間のパートナーの許可なしに例外なし。

制限事項

• このスキルを、上記で説明されたスコープと明確に一致するタスク時のみ使用する。
• 出力を、環境固有の検証、テスト、または専門家レビューの代替として扱わない。
• 必要な入力、権限、安全境界、または成功基準が不足している場合は停止して明確化を求める。