テスト駆動開発（TDD）

状況: 従業員15名のEC企業のバックエンドチーム。新しいカート機能を開発することになり、TDDで実装を進める。

Red 1: テスト「空のカートの合計は0円」を書く。Cartクラスがないのでテストは失敗。

Green 1: Cartクラスを作り、total()が0を返すようにする。テスト通過。

Red 2: テスト「商品1つ（500円）をカートに入れると合計500円」を書く。add()メソッドがないのでテスト失敗。

Green 2: add()メソッドを追加し、total()が商品の合計を返すようにする。テスト通過。

Red 3: テスト「同じ商品を2つ入れると合計1000円」を書く。→ Green 3: 数量を考慮した計算に修正。

Red 4: テスト「10%割引クーポン適用で合計900円」を書く。→ Green 4: クーポンロジック追加。

Refactor: 金額計算のロジックをメソッドに切り出し、変数名を整理。全テストがGreenのままであることを確認。

実装時間**+25%、リリース後バグ0件**。「テストは後で書く」が実行される確率は限りなく低い。先に書く方が結局速い。

状況: 従業員80名のFinTech企業。決済処理APIのcalculateFee()関数が800行に肥大化。手数料計算のロジックが複雑すぎて、誰も安心して修正できない状態。テストはゼロ。

TDDでのリファクタリング手順:

1. まず既存のcalculateFee()の振る舞いをテストで記録（既存の入出力をテスト化）
2. テスト通過を確認（ここでGreenの状態を確保）
3. テストを安全網にしながら、800行の関数を段階的に分割

結果:

800行→12関数×平均40行。手数料バグは月2.3件→0.1件。障害ゼロでリファクタリングを完了できたのは、先にテストで振る舞いを「固めた」からにほかならない。

状況: 従業員30名の医療IT企業。薬の処方箋を電子化するアプリで、薬の相互作用（飲み合わせ）チェック機能を開発する。誤った判定が患者の命に関わるため、バグは許されない。

TDDの適用:

• Red: 「アスピリンとワルファリンの併用は警告を出す」テストを書く
• Green: 相互作用データベースを参照して判定するコードを書く
• Red: 「用量が安全範囲内なら警告しない」テストを書く
• Green: 用量チェックロジックを追加
• Refactor: 相互作用判定と用量チェックを別クラスに分離

テストケース: 3ヶ月の開発で487のテストケースを作成（正常系185、異常系302）。

重大バグ12件→1件、本番障害0件。487のテストケースが24時間365日、処方箋チェックの正しさを検証し続けている。人命に関わるソフトウェアでは、TDDは品質手法ではなく安全装置。