test-driven-development

テスト駆動開発

TDDの絶対的なルール

テストより先にコードを書きましたか？ そのコードを削除して、最初からやり直してください。

これは交渉の余地がありません。選択肢でもありません。もっともらしい理由をつけて逃れることはできません。

RED-GREEN-REFACTORサイクル

1. RED - まず失敗するテストを書く

• 正しい理由で失敗する、最小限のテストを書きます
• 機能がまだ存在しないためにテストが失敗するようにします
• テストを実行し、失敗することを確認します

2. GREEN - テストを通す（最小限のコード）

• テストを通すために必要な最小限のコードを書きます
• 必要以上に書かないでください
• まだ最適化しないでください
• まだリファクタリングしないでください

3. REFACTOR - コードを改善する

• ここでコードを整理できます
• 重複を取り除きます
• 名前を改善します
• メソッドや関数を抽出します
• リファクタリング後も、すべてのテストが通る必要があります

禁じられた言い訳

次のいずれかを考えていることに気づいたら、すぐにやめてください。

• 「これは単純な関数にすぎない」→ 間違いです。単純な関数にもテストが必要です。
• 「あとでテストを書く」→ 間違いです。それはTDDではありません。
• 「まず動くようにするだけ」→ 間違いです。テストが先です。
• 「これはテストしなくていい」→ 間違いです。すべてにテストが必要です。
• 「手動でテストする」→ 間違いです。自動テストを書いてください。
• 「テストは明らかだ」→ 間違いです。それでも書いてください。
• 「ただ調べているだけ」→ 間違いです。テストを使って調べてください。

テスト品質のガイドライン

優れたテストとは：

• 高速 - テストはミリ秒単位で実行されること
• 独立 - テスト間に依存関係がないこと
• 再現可能 - 毎回同じ結果になること
• 自己検証可能 - 解釈の余地なく、成功か失敗かが分かること
• 適時 - コードより前に書かれていること

テストの構成（準備・実行・検証）：

// Arrange - Set up the test conditions
const input = createTestInput();

// Act - Execute the code under test
const result = functionUnderTest(input);

// Assert - Verify the expected outcome
expect(result).toBe(expectedValue);

このスキルを使うタイミング

• 新しい機能に着手するとき
• バグを修正するとき（まず、そのバグを再現するテストを書きます）
• 既存のコードをリファクタリングするとき（まず、テストがあることを確認します）
• 既存の機能を壊す可能性のあるコード変更をするとき

YAGNI（必要になるまで作らない）

まだ必要のないコードを書かないでください。

• 先を見越した機能は追加しない
• 「念のため」の抽象化はしない
• 時期尚早な最適化はしない
• 今必要なものだけを作り、それ以上は作らない

DRY（同じことを繰り返さない）

ただし、REFACTORフェーズでのみ適用します。

• まず動くようにする（GREEN）
• 次に正しくする（REFACTOR）
• 一時的な重複は問題ありません
• リファクタリング時に取り除きます

コミット戦略

• GREENのたびにコミットします
• REFACTORのたびにコミットします
• 小さく、頻繁にコミットします
• 各コミットですべてのテストが通るようにします