テスト駆動開発（TDD）の考え方

Kentが見つけた「バグを作らない」魔法

1999年、Chrysler社のオフィス。

Kent Beck は頭を抱えていた。C3プロジェクト（Chrysler Comprehensive Compensation System）で、給与計算システムの開発が大混乱に陥っていた。

コードを書く。テストする。バグが見つかる。修正する。別のバグが発生する。また修正する。さらに新しいバグが…

この無限ループを見ていたKentは、ある日ふと思った。

「もしテストを先に書いたらどうなるだろう？」

常識に反するアイデアだった。当時、テストはコードを書いた後にするものだった。しかし、Kentは試してみた。

まず、給与計算の小さな機能について「こうあるべき」という期待をテストで表現した。当然、テストは失敗した。まだコードが存在しないからだ。

次に、そのテストが通るために必要な最小限のコードだけを書いた。テストは成功した。

そして、コードをより良くするためにリファクタリングした。テストが保証してくれるので、安心して変更できた。

3ヶ月後、驚くべきことが起きた。C3プロジェクトのバグ発生率が90%減少した。開発速度は2倍に向上した。チームの士気も大幅に改善した。

Kentはこの手法を「テスト駆動開発（Test-Driven Development）」と名付けた。後に世界中の開発者に影響を与える革命の始まりだった。

Twitterの140文字が教えた真実

2006年、Twitter創業間もない頃。

エンジニアのJack Dorsey は、ツイートの文字数制限機能を実装していた。シンプルに見える機能だったが、実装してみると予想外の複雑さがあった。

通常の文字、絵文字、URL、改行文字。それぞれの文字数カウント方法が異なる。日本語のような全角文字はどうカウントする？短縮URLは元のURLの長さ？それとも短縮後の長さ？

Jackは最初、いつものように実装から始めた。

function countCharacters(text) {
  return text.length; // シンプルに見えるが...
}

しかし、テストしてみると問題が山積みだった。

「👍」という絵文字が2文字としてカウントされる。URLが予想より長くカウントされる。改行が思ったように処理されない。

修正を重ねるうちに、コードはスパゲッティ状態になった。新しい修正が別の機能を壊す。修正の修正がさらなる問題を生む。

その時、Jackは Kent Beck の「Test-Driven Development: By Example」を読んでいた。試しにTDDアプローチを使ってみることにした。

まず、期待する動作をテストで表現した：

// 最初に「こうあるべき」を明確にする
test('基本的な英数字のカウント', () => {
  expect(countCharacters('Hello')).toBe(5);
});

test('絵文字は1文字としてカウント', () => {
  expect(countCharacters('Hello👍')).toBe(6);
});

test('URLは短縮後の長さでカウント', () => {
  expect(countCharacters('Check this http://example.com/very/long/url'))
    .toBe('Check this t.co/abc123'.length);
});

テストを書いてから実装に取り掛かると、不思議なことが起きた。

何を実装すべきかが明確になった。複雑に見えた要件が、小さな明確な問題に分解された。各問題を一つずつ解決していけば良いことがわかった。

6週間後、文字数カウント機能は完成した。以前の実装より複雑な要件を満たしているにも関わらず、コードはよりシンプルで理解しやすかった。

最も重要なのは、この機能が安定していることだった。その後5年間、文字数カウントに関する重大なバグは一度も発生しなかった。

Jackは言う。「TDDは単なるテスト手法ではない。問題を考える新しい方法だ」

赤・緑・リファクタ：信号機が教える開発リズム

2010年、GitHub。

創業者の一人、Chris Wanstrath は、プルリクエスト機能を開発していた。複雑な機能だった。コードの差分表示、コメント機能、マージ処理、権限管理。すべてが密接に関連している。

しかし、ChrisはTDDの「Red-Green-Refactor」サイクルを徹底的に実践することにした。

Red（赤）：失敗するテストを書く

まず、最小の機能について「こうあるべき」をテストで表現する。

test('プルリクエストを作成できる', () => {
  const pr = new PullRequest({
    title: '新機能の追加',
    baseBranch: 'main',
    headBranch: 'feature-branch',
    author: 'chris'
  });
  
  expect(pr.title).toBe('新機能の追加');
  expect(pr.status).toBe('open');
});

このテストは失敗する。当然だ。まだ PullRequest クラスが存在しないから。

Green（緑）：テストを通すための最小限のコード

次に、テストが通るために必要な最小限のコードだけを書く。

class PullRequest {
  constructor(options) {
    this.title = options.title;
    this.baseBranch = options.baseBranch;
    this.headBranch = options.headBranch;
    this.author = options.author;
    this.status = 'open';
  }
}

テストが通った。緑になった。ここで重要なのは、「最小限」にとどめることだ。将来必要になるかもしれない機能は実装しない。

Refactor（リファクタ）：コードをより良くする

テストが保証してくれるので、安心してコードを改善できる。

class PullRequest {
  constructor(options) {
    this.validateOptions(options);
    this.title = options.title;
    this.baseBranch = options.baseBranch;
    this.headBranch = options.headBranch;
    this.author = options.author;
    this.status = PullRequestStatus.OPEN;
  }
  
  private validateOptions(options) {
    if (!options.title || options.title.trim() === '') {
      throw new Error('Title is required');
    }
    // 他のバリデーション...
  }
}

このサイクルを繰り返す。次のテスト、次の実装、次のリファクタリング。

6ヶ月後、プルリクエスト機能はリリースされた。GitHubの最も重要な機能の一つとなり、現在でも世界中の開発者に愛用されている。

Chrisは振り返る。「Red-Green-Refactorは開発のリズムを作ってくれた。まるで信号機のように、次に何をすべきかを教えてくれる」

Shopifyの100万行コードが壊れなかった理由

2015年、Shopify。

同社のeコマースプラットフォームは急成長していた。しかし、コードベースも急速に拡大し、100万行を超えていた。

普通なら、この規模のコードベースでは大規模なリファクタリングは不可能だ。一つの変更が予想外の場所でバグを引き起こす。デグレーション（機能退行）のリスクが高すぎる。

しかし、ShopifyのエンジニアリングVP、Jean-Michel Lemieux は大胆な決断をした。

「決済システム全体を作り直す」

Shopifyの生命線とも言える決済処理。年間数百億ドルの取引を処理するシステム。一つのバグが数千の店舗に影響を与える。

普通の会社なら、この決断は自殺行為だ。しかし、ShopifyにはTDDによって築かれた、包括的なテストスイートがあった。

決済関連のテストだけで2万件以上。すべてのエッジケース、すべての例外処理、すべてのビジネスルールがテストでカバーされていた。

リファクタリングが開始された。レガシーな決済コードが段階的に新しいアーキテクチャに置き換えられていく。

毎日、自動テストが実行される。2万件のテスト。一つでも失敗すれば、その日の変更は取り消される。

3ヶ月間のリファクタリング期間中、本番環境で決済関連のバグは一件も発生しなかった。

新しい決済システムは旧システムより30%高速で、コードも50%簡潔だった。そして何より、今後の機能追加が格段に容易になった。

Jean-Michel は言う。「TDDのテストスイートは、リファクタリングの安全網だ。これがなければ、Shopifyの規模でのリファクタリングは不可能だった」

Facebookの「Move Fast and Break Things」からの転換

2012年、Facebook。

Mark Zuckerberg の有名なモットー「Move Fast and Break Things（高速で動き、壊せ）」が問題を引き起こしていた。

確かに開発は高速だった。新機能が毎日のようにリリースされる。しかし、「壊れるもの」が多すぎた。

ユーザーのタイムラインが正常に表示されない。メッセージが送信されない。友達申請が機能しない。毎日のように大小のバグが発生していた。

エンジニアリング担当VPのMike Schroepfer は危機感を抱いていた。「このままでは、成長とともに品質が悪化し続ける」

2013年、MikはFacebookの開発文化を大きく変える決断をした。TDDの導入だ。

しかし、既に10億人のユーザーを持つプラットフォームでTDDを導入するのは容易ではなかった。

段階1：新機能からTDDを開始

まず、新機能の開発にTDDを必須とした。Facebook Stories、Marketplace、Reactionsなど、主要な新機能はすべてTDD で開発された。

段階2：既存機能にテストを追加

レガシーコードにも段階的にテストを追加。バグが発見されるたびに、そのバグを防ぐテストを追加してから修正する。

段階3：リファクタリングの安全網

包括的なテストスイートにより、大規模なリファクタリングが可能になった。

2016年、Mark Zuckerberg は新しいモットーを発表した。

「Move Fast with Stable Infra（安定したインフラで高速に動く）」

TDDによって、Facebookは高速な開発と高い品質を両立させることに成功した。現在のMeta（旧Facebook）の安定性は、このTDD文化の上に築かれている。

Stripeの99.99%可用性を支える哲学

2017年、Stripe。

オンライン決済のインフラを提供する同社にとって、システムの安定性は生命線だった。一分間のダウンタイムが、数千の企業の売上に直接影響する。

しかし、Stripeは急成長していた。毎月新しい機能が追加され、新しい国でサービスが開始される。変化のスピードと安定性の両立は可能なのか？

StripeのCTO、David Singleton の答えは明確だった。「TDDこそが、変化と安定性を両立させる方法だ」

Stripeの開発プロセスは徹底していた。

すべての機能はテストから始まる

決済処理、不正検知、通貨換算、税金計算。どんな小さな機能でも、まずテストを書く。

// Stripeの決済処理テスト例（簡略化）
test('クレジットカード決済が成功する', async () => {
  const payment = await stripe.payments.create({
    amount: 1000,
    currency: 'usd',
    payment_method: 'pm_card_visa'
  });
  
  expect(payment.status).toBe('succeeded');
  expect(payment.amount).toBe(1000);
});

test('不正なカード番号は拒否される', async () => {
  await expect(stripe.payments.create({
    amount: 1000,
    currency: 'usd',
    payment_method: 'pm_card_invalid'
  })).rejects.toThrow('Invalid payment method');
});

エッジケースの徹底的な検証

決済システムでは、エッジケースが致命的なバグにつながる。0円の支払い、負の金額、存在しない通貨、期限切れのカード。ありとあらゆるケースがテストされる。

本番環境と同じ条件でのテスト

Stripeのテスト環境は、本番環境とほぼ同じ構成。実際のカード番号（テスト用）、実際の銀行API（テスト用）、実際のネットワーク遅延を再現。

結果は驚異的だった。

Stripeの可用性：99.99%以上（年間ダウンタイム1時間未満） 決済成功率：99.5%以上（業界最高水準） 新機能デプロイ頻度：1日平均5回（安定性を保ちながら）

David は言う。「TDDは保険ではない。品質そのものを作り出す方法だ」

Netflixのカオステストが証明した真実

2018年、Netflix。

同社の「Chaos Engineering」は有名だが、あまり知られていない事実がある。Chaos Engineering が成功した理由の一つが、TDDによって構築された堅牢なテストスイートだった。

Chaos Monkey（本番環境でサーバーをランダムに停止させるツール）を初めて実行した時、多くのサービスが影響を受けた。しかし、興味深いことに、TDDで開発された新しいサービスは影響を受けなかった。

なぜか？

TDDで開発されたコードは、自然に障害に強い設計になっていたからだ。

// TDDによって自然に生まれる障害対応パターン
test('外部APIが失敗した時のフォールバック', async () => {
  // 外部サービスの失敗をシミュレート
  mockExternalAPI.mockRejectedValue(new Error('Service unavailable'));
  
  const result = await recommendationService.getRecommendations('user123');
  
  // キャッシュされたレコメンデーションを返すことを期待
  expect(result).toEqual(cachedRecommendations);
  expect(result.source).toBe('cache');
});

test('データベースが一時的に使用不可能な場合', async () => {
  mockDatabase.mockRejectedValue(new Error('Database timeout'));
  
  const result = await userService.getUserProfile('user123');
  
  // デフォルトプロファイルを返すことを期待
  expect(result.isDefault).toBe(true);
  expect(result.username).toBe('user123');
});

TDDでは、「正常系」だけでなく「異常系」のテストも必然的に書くことになる。これが、障害に強いコードを生み出していた。

Netflix のエンジニア、Nora Jones は言う。「TDDとChaos Engineering は相性が良い。TDDが作り出した堅牢なコードが、Chaosテストに耐えられる」

実践への第一歩：小さく始める勇気

ここまで見てきた事例が示すのは、TDDの真価は技術的な効果だけではないということだ。

TDDは考え方を変える。「どう作るか」から「何を作るべきか」への転換。

では、あなたのプロジェクトでTDDを始めるには？

Week 1-2: 一つの小さな機能から

完璧なプロジェクト構造を目指さない。まず、一つの小さな機能でRed-Green-Refactorを体験する。

// 最初の小さな一歩
test('消費税を計算できる', () => {
  expect(calculateTax(100, 0.1)).toBe(10);
});

// この時点ではcalculateTax関数は存在しない（Red）
// 次に最小限の実装を書く（Green）
// 最後にコードを改善する（Refactor）

Week 3-4: テストの習慣化

新しい機能を追加するとき、必ずテストから書き始める。まだ既存コードは変更しなくて良い。新しい部分だけでも効果がある。

Month 2-3: チーム全体での実践

一人での成功体験をチームに共有する。ペアプログラミングでTDDの知識を広める。

Month 4-6: 既存コードの改善

バグが発見されたとき、まずそのバグを再現するテストを書いてから修正する。これにより、既存コードにも段階的にテストが追加される。

重要なのは、完璧を求めないことだ。Kent Beck、GitHub、Shopify、Facebook、Stripe、Netflix。どの組織も最初から完璧ではなかった。小さな改善を積み重ね、文化を変革し、結果として大きな成果を得ている。

TDDは目的地ではない。それは新しい思考方法だ。そして、その思考方法は今日から始めることができる。

あなたのコードも、明日から少し違った書き方を始めてみてはどうだろうか。

テストを書いてから実装を始める。たったそれだけの変化が、やがて大きな変革をもたらすかもしれない。