なぜテストが重要なのか

ストーリー

「レビューの次はテストだ。この2つは品質保証の両輪なんだ」

松本先輩がインシデント報告書を見せてくれた。

「先月の障害、覚えているか？本番で注文金額が マイナスになるバグがあった。テストが1つでもあれば 防げたんだ。テストを書かないのは、 シートベルトをしないで運転するようなものだ」

「テストの重要性を数字で理解しよう」

テストがない世界

バグ修正コストの増大

バグの発見が遅れるほど、修正コストは指数関数的に増大します。

バグ修正コストの増大（相対コスト）

開発中     テスト中      本番リリース後
  1x         10x            100x

  ┃           ┃              ┃
  ┃           ┃              ┃
  ┃           ┃         ┌────┤
  ┃           ┃         │    │ 100x
  ┃           ┃         │    │
  ┃      ┌────┤         │    │
  ┃      │    │ 10x     │    │
  ┃      │    │         │    │
  ┌──────┤    │         │    │
  │  1x  │    │         │    │
  └──────┴────┴─────────┴────┘

テストがないプロジェクトの末路

最初: 「テスト書く時間がない。手動で確認すればいい」
  ↓
3ヶ月後: 「機能追加のたびに既存機能が壊れる」
  ↓
6ヶ月後: 「怖くてコードを変更できない」
  ↓
1年後: 「リファクタリングもできず技術的負債が蓄積」
  ↓
2年後: 「ゼロから作り直した方が早い」

テストのメリット

1. バグの早期発見

// テストがあれば、このバグは即座に見つかる
function calculateDiscount(price: number, rate: number): number {
  return price * rate;  // バグ: (1 - rate) であるべき
}

// テスト
test('10%割引で100円が90円になる', () => {
  expect(calculateDiscount(100, 0.1)).toBe(90); // 失敗！ 10が返る
});

2. リファクタリングの安全網

テストがある場合のリファクタリング:

1. 全テストが通ることを確認 ✅
2. コードを変更
3. 全テストを再実行
4. 全テストが通れば、振る舞いが保たれている ✅
5. 安心してマージ

3. 仕様書としてのテスト

// テストを読めば仕様が分かる
describe('パスワードバリデーション', () => {
  it('8文字以上であること', () => { /* ... */ });
  it('大文字を1つ以上含むこと', () => { /* ... */ });
  it('数字を1つ以上含むこと', () => { /* ... */ });
  it('特殊文字を1つ以上含むこと', () => { /* ... */ });
  it('過去3回分のパスワードと異なること', () => { /* ... */ });
});
// → テスト名を見るだけで、パスワードの仕様が理解できる

4. 開発速度の向上

一見矛盾するように聞こえますが、テストは開発速度を向上させます。

テストなし:
  コード変更 → 手動確認(5分) → 別の画面も確認(10分) → 見落とし → バグ → 修正(30分)
  = 45分

テストあり:
  コード変更 → テスト実行(10秒) → 失敗を発見 → 即修正(5分)
  = 5分

テストに関するよくある誤解

まとめ

チェックリスト

• バグ修正コストの増大を数字で説明できる
• テストの4つのメリットを説明できる
• テストに関するよくある誤解を論破できる
• テストが仕様書として機能することを理解した

次のステップへ

テストの重要性を理解したら、次はテストの種類と戦略を学びます。ユニットテスト、インテグレーションテスト、E2Eテストの違いとテストピラミッドを理解しましょう。

推定読了時間: 20分