テスト駆動開発

テスト駆動開発とは

テスト駆動開発(TDD:Test-Driven Development)は、実装より先にテストを書く開発手法です。「テストは実装の後に書くもの」という常識を逆転させ、テストを設計の道具として使います。

TDD は次の3ステップを短いサイクルで繰り返します。

なぜ先にテストを書くのか

• 仕様が明確になる — テストを書くには「何ができたら完成か」を先に決める必要があります
• 使いやすい設計になる — テストは最初の利用者。呼び出しにくいコードはテストも書きにくいため、自然と使いやすい形になります
• 安心して変更できる — テストが常にあるので、[[リファクタリング]] で壊してもすぐ気づけます
• デグレを防ぐ — 過去のバグの再発をテストが検知してくれます

// レッド: まだ存在しない関数のテストを先に書く
test('税込価格を計算する', () => {
  expect(withTax(100)).toBe(110);
});

// グリーン: テストを通す最小限の実装
function withTax(price) {
  return Math.floor(price * 1.1);
}

初学者向けポイント

• 「グリーン」の段階ではきれいさより通ることを優先します。整理はリファクタリングの段階で行う、と役割を分けるのがコツです
• 1サイクルは数分単位が理想です。大きな機能はテストできる小さな単位に分割します
• すべてのコードに TDD を適用する必要はありません。ロジックが複雑な部分ほど効果が高く、画面の見た目などは相性が良くありません
• TDD は [[自動テスト]] の書き方ではなく開発の進め方です。テストの実行環境(テスティングフレームワーク)は前提知識として押さえておきましょう

関連技術とのつながり

• [[自動テスト]] — TDD の前提となるテストの種類と書き方
• [[テストダブル(モック・スタブ)]] — 外部依存を差し替えて短いサイクルを回す道具
• [[リファクタリング]] — TDD サイクルの第3ステップ。テストがあるから安全にできる
• [[クリーンコード]] — TDD が導く「使いやすい設計」の指針
• [[CI/CD]] — 書いたテストを毎回自動実行し、常にグリーンを保つ仕組み

Q: TDD のサイクルとして正しい順番はどれ?
- [x] テストを書いて失敗させる → 最小限の実装で通す → リファクタリング
- [ ] 実装する → テストを書く → リリースする
- [ ] リファクタリング → 実装 → テストを書く
解説: レッド(失敗するテスト)→ グリーン(最小限の実装)→ リファクタリングの順で短いサイクルを繰り返します。

Q: 「グリーン」の段階で優先すべきことはどれ?
- [ ] 将来を見越した完璧な設計にすること
- [x] テストを通す最小限の実装を書くこと
- [ ] テストを削除して失敗をなくすこと
解説: グリーンではまず通すことを優先し、コードの整理は次のリファクタリング段階で行います。

Q: 先にテストを書くことの利点として本文で挙げられているのはどれ?
- [ ] テストを書かなくてもよくなる
- [ ] コードの実行速度が必ず速くなる
- [x] 「何ができたら完成か」が明確になり、使いやすい設計になる
解説: テストを先に書くには完成条件を決める必要があり、またテストは最初の利用者としてコードを使いやすい形に導きます。