テスト駆動開発（TDD）入門

テスト駆動開発（TDD）入門

長い間、私はほとんどの開発者と同じように、コードを書いた後にテストを書いていました。機能を完成させ、それなりに満足したら、それが意図した通りに動作することを確認するためにテストを書いていました。テストはいつもパスしていました。それが私の最初の間違いでした。

ある日の午後、私はユーティリティ関数をリファクタリングしました。クリーンアップして「より良く」したのですが、2日間気づかないうちに壊してしまいました。既存のテストは私の実装をテストしており、振る舞いをテストしていなかったのです。実装を変更すると、テストもそれに追従しました。QAが発見するまで、誰もそれに気づきませんでした。

その時、私は実際にTDDを試しました。誰かに言われたからではなく、その特定の失敗パターンにうんざりしていたからです。

TDDサイクル

TDDは3つのステップを繰り返すリズムに従います。数回行えば、それは筋肉の記憶になりますが、最初の数回は逆行しているように感じるでしょう。

具体的な例：乗算

教科書的な例は小さいですが、ゆっくりと取り組む価値はあります。

test('multiplies two numbers', () => {
  expect(multiply(3, 4)).toBe(12);
});

function multiply(a, b) {
  return a * b;
}

型安全性を追加した後の、正しさへのリファクタリングは次のようになります。

11 function multiply(a, b) {
2+  if (typeof a !== 'number' || typeof b !== 'number') {
3+    throw new TypeError('Both arguments must be numbers');
4+  }
25   return a * b;
36 }

なぜ実際に機能するのか

私は、要件が不明確なコードの一部でTDDを試すまで、設計上の利点について懐疑的でした。まずテストを書くことで、私は「これは実際に何をすべきか？」と問うことを余儀なくされました。ロジックを書く前にインターフェースを定義しなければなりませんでした。それが、より困難で、より重要な問いであることが判明しました。

どこから始めるか

小さく始めましょう。ユーティリティ関数 — フォーマッター、バリデーター、何か自己完結型のもの — を選びましょう。まずテストを書き、それが失敗するのを見て、それからパスさせます。ワンサイクルです。どんな感じか見てみましょう。

設計上の利点は、3行の関数では現れません。それは、真の複雑さを持つものを構築しているときに現れ、テストがAPIがどこで混乱しているか、ロジックが多すぎる責任を負っているかを常に教えてくれるときに現れます。それがTDDの仕事です。

こちらもおすすめ

• Mastering E2E Testing with Playwright in 2026
• Playwright Visual Regression Testing & Pixel Match Guide
• Next.js Hydration Errors: Complete Guide to Error #418, #423 & Text Content Mismatch (2026)
• React in Practice: Production Patterns, Hook Discipline, and Common Pitfalls