コンテンツにスキップ
Process Compass（プロセスコンパス）

テスト駆動開発(TDD)

既存プロセスの体系 ／ 種別: 実務プラクティス(開発者レベルの技法)

失敗するテストを先に書き(Red)、通す最小限のコードを書き(Green)、重複を除去して設計を整える(Refactor)短いサイクルを反復してコードを育てる開発技法

ひとことで言うと: 「先にテストを書いてから、それを通すコードを書く」を数分単位で繰り返す進め方。テストが仕様と検査を兼ねる。開発者一人のミクロな作業技法で、スクラム等の内側で使う

全体マップ(第1階層)

各フェーズをクリックすると、フェーズ内のワークフロー(第2階層)へ移動します。

graph LR
  ph0["テストリストの作成"]
  ph1["Red → Green → Refactor サイクル"]
  ph0 --> ph1
  gEnd{"Refactor 後の再検査"}
  ph1 --> gEnd
  click ph0 "/process-compass/processes/tdd/prepare/" "テストリストの作成の詳細へ"
  click ph1 "/process-compass/processes/tdd/cycle/" "Red → Green → Refactor サイクルの詳細へ"

目的と成果

目的(purpose): 「動作する、きれいなコード」を得ること。振る舞いの変更を、既存機能とチームの自信を保ちながら少しずつ安全に進める

成果(outcomes):

  • 実装と同時に自動化された回帰テスト群(self-testing code)が蓄積する
  • 各機能に対応する失敗→成功の履歴が残る
  • 重複が除去され設計が漸進的に改善される
  • 欠陥密度が下がる(実証研究で非TDD比 40〜90% 減の報告)

原典: Kent Beck。XP の一部として1990年代後半に体系化(公開デモ1995年)。原典『Test-Driven Development: By Example』(2002)。近年 Beck が Canon TDD(2023)で再定義

ISO/IEC/IEEE 12207 対応: 主に「テクニカル(実装プロセスと単体検証をミクロに融合。設計にも創発的設計として食い込む)」プロセス群をカバー

ロール

ロール責任日本の現場での実態
開発者(Developer)テストリスト作成・テスト作成・実装・リファクタリングのすべてを一人で担う。テストの書き手とコードの書き手が同一人物TDD 単体では兼務問題は起きない。ただし「テストは QA の仕事」という職掌分離意識が強い組織では開発者がテストを書くこと自体に抵抗が生じる
ペア相手(任意)ペアプログラミングと組み合わせる場合、もう一人がナビゲータとして即時レビューするXP 由来のためペアが本来想定だが、日本ではペアプロ自体の普及が限定的で単独 TDD が多い

ゲート(決裁・レビュー)

ゲート種別Deliverables判定基準判定者判定結果
Red ゲート(失敗確認)検査と適応書いたばかりのテスト1件テストが失敗する(または未コンパイル)こと。通ってしまったらテストか対象が間違いテストランナー(機械)+開発者失敗=期待どおり(Green へ) / 通過=テスト見直し
Green ゲート(通過確認)検査と適応プロダクションコード+全既存テストすべてのテストがグリーンであることテストランナー(機械)全緑(Refactor へ) / 一部赤(実装続行)
Refactor 後の再検査 ※判定者が人間でなく自動テスト、判定周期が秒〜分、判定結果がコードの前進/巻き戻し。WF のフェーズゲートとは根本的に別物検査と適応リファクタ済みコード+全テストリファクタ後も全緑を維持していること(振る舞い不変の保証)テストランナー(機械)全緑(サイクル完了) / 赤(リファクタを戻す)

成果物(information items)

成果物作成者説明
テストリスト(TODOリスト)開発者(Developer)サイクルの起点。実装対象の棚卸し。使い捨て(コードには残らないことが多い)
テストコード(自動化テスト)開発者(Developer)実装の仕様(先に書く)+回帰テストの安全網(以後永続)+リファクタリングの保証。CI に組み込まれ後続の全変更を検査する
プロダクションコード開発者(Developer)本体。テストを満たす形で漸進的に育つ。設計はリファクタで創発する

アンチパターン(建前 vs 実態)

なんちゃって TDD(Test-Last を TDD と称する)

建前(あるべき姿)テストを先に書き(Red)、それを通すコードを書く(テストファースト)
実態実装後にテストを追加するのに「TDD」と称する(semantic diffusion)
なぜ起きるか「自動テストを書く=TDD」という混同。Beck が Canon TDD を書いた動機そのもの
弊害テストが設計を駆動せず、TDD の設計フィードバック効果が失われる

Refactor の省略

建前(あるべき姿)グリーン後に必ず重複除去・設計改善を行う
実態緑になったら次のテストへ進み、設計改善を飛ばす
なぜ起きるか納期圧力。動けばよいという判断
弊害コード断片の寄せ集めになり、設計が劣化していく

建前と実運用(日本の現場)

  • 受託開発では「テストを書く工数」が見積り・契約に明示計上されず、開発者がこっそりやるか、テストが別工程(QA)に切り離される
  • テストコードも保守対象になるという二重保守コストへの理解・合意が組織的に得られにくい(最大の障壁)
  • 第一人者 t_wada は「学習コストが最大のハードル。写経と実践でしか身につかない」とし、トップダウン強制でなく任意参加のボトムアップ普及を推奨している

フェーズ一覧(第2階層へ)

  • テストリストの作成 — サイクル開始前の準備。実装ではなく設計思考。「テストを先に書く」だけでは不十分で、シナリオの棚卸しが起点
  • Red → Green → Refactor サイクル — TDD の中核。テスト1件分の高速反復(分〜秒単位)。テストリストが空になるまで繰り返す

参考文献