2025.08.29 プラットフォーム

TDDとは？テスト駆動開発の基本サイクルと導入判断を実装者向けに解説

TDDとは、実装より先にテストコードを書き、そのテストを通す最小限のコードを足してから設計を整える開発手法です。読み方は「テスト駆動開発」、英語では Test-Driven Development という表記です。この記事では、Red・Green・Refactor という基本サイクルの回し方、テストファーストやBDDとの線引き、JUnit 6系とpytest 9系で組むテスト基盤、テストが1本も無いレガシーコードへ段階導入する順序までを扱います。加えて、生成AIがコードの初稿を書く前提でTDDの費用対効果がどう変わるか、どういう条件なら採用を見送るべきかも条件付きで示します。

まとめ：TDDを採用する条件と見送る場面の判断基準

TDDの正体は、テストを増やす活動ではありません。テストという形で仕様を先に固定し、実装の自由度をわざと狭める設計手法です。だからテストの本数ではなく、仕様が先に決まるかどうかで効き方が変わります。

採用して効くのは、製品寿命が長く仕様変更が続くコード、複数人が同じモジュールを触るコード、そして分岐や境界値が多く目視確認では抜けが出るロジックです。この3条件のどれかに当てはまるなら、初期の工数増を回収できる見込みが立ちます。逆に、捨てる前提の検証コード、画面の見た目そのものの調整、外部仕様が固まっていない探索段階の実装では、先にテストを書いても書き直しが発生して損になります。

導入の順序も結論から言えます。既存コードへ一気に広げるやり方は失敗します。修正頻度の高いモジュールを1つ選び、そこに現状の振る舞いを固定するテストを置き、以降の修正だけテストファーストにする。この局所導入から始めるのが現実的な進め方です。判断に迷う場面ごとの条件は、以降の章で分解します。

TDDの定義とRed・Green・Refactorが循環する仕組みの全体像

まず用語と手順を固定しておきましょう。TDDは「設計してから実装し、最後にテストする」という従来の順序を反転させ、テストを起点に機能を組み立てます。反転の目的は品質検査ではなく、実装前に仕様を検証可能な形へ落とすことにあります。

TDDの定義とKent Beckが体系化した手法としての位置づけ

TDDは、エクストリーム・プログラミング（XP）のプラクティス群のひとつとして Kent Beck 氏が整理し、書籍『Test-Driven Development: By Example』（2002年刊）で手順として明文化した手法です。ルールは短く、失敗するテストを書く、通す、整える、の3つしかありません。それでも設計手法として扱われる理由は、テストから書くと呼び出し側の都合が先に決まるためです。引数の並び、戻り値の形、例外の投げ方が、利用者視点で決まっていきます。Beck 氏は後年、サイクルの本質を「テストの一覧を作り、1件ずつ通し、都度整える」という形で再整理しており、テスト自動化そのものが目的ではないと繰り返し述べています。

Redフェーズで失敗するテストを先に書く狙いと確認方法の手順

Redフェーズでは、まだ存在しない機能を呼び出すテストを書き、意図的に失敗させます。失敗を確認する工程を省くと、実は何も検証していないテスト（常に通るテスト）を作り込んでも気づけません。書き方は、入力値と期待値を具体的な定数で書き下すのが基本です。assertEquals の期待値に計算式を書くと、実装のバグがテストにも同じ形で入り込みます。ここで書くテストは1件だけに絞ります。5件まとめて赤くしてから実装に入ると、どの実装がどのテストを通したのか対応が取れなくなり、失敗の原因追跡ができません。

Greenフェーズで最小実装に絞る判断基準とやり過ぎの兆候例

Greenフェーズの目的は、テストを通すことだけです。設計の美しさ、将来の拡張性、性能はいったん脇に置きます。極端な話、定数を返すだけの実装でテストが通るなら、その時点ではそれで構いません。次のテストが定数返しを許さなくなり、そこで初めて一般化します。この進め方を Beck 氏は「仮実装から一般化へ」と呼びました。やり過ぎの兆候は明確です。まだテストで要求していない分岐、設定値、抽象クラスを足し始めたら、それは仕様ではなく想像に基づく実装です。テストが要求していないコードは書かない、という制約が過剰設計の抑止になります。

Refactorフェーズを飛ばした場合に蓄積する設計劣化の兆候

3つ目の工程を省いたTDDでは、ほぼ確実に破綻を避けられません。仮実装の積み重ねが残るため、重複した条件分岐と長いメソッドが増え、テストは緑のまま設計だけが腐ります。この状態は「テストがあるから安全」という誤った安心感を生むので、テストが無い状態より危うい場面もあります。挙動を変えずに内部構造だけ直す作業の具体的な観点とタイミングはリファクタリングとは？24の観点とタイミング・進め方で分類しているため、Refactorフェーズで何を直すか迷う場合はそちらを手順書として使ってください。メソッド抽出、命名の修正、重複の統合が中心になります。毎周この工程を挟んでおくと、返済を後回しにした技術的負債が一度に膨らむ事態を避けられます。

TDDが効きやすいプロジェクト規模と製品寿命を測る判断の目安

効き方はすべての案件で均一ではありません。テストを書く工数は最初に前払いし、回収は変更のたびに少しずつ生じる構造です。したがって変更回数が少ないコードでは、回収前に案件が終わってしまいます。目安として、リリース後も1年以上の保守が前提で、開発者が3人以上関わり、同じモジュールに複数人が手を入れるなら前払い分は回収できます。逆に、1人で2週間で作って捨てる検証用スクリプトに全面適用する合理性はありません。中規模以上の業務システム、課金や在庫のように誤りが金額へ直結する領域、外部連携の仕様が文書化されていない領域が、投資効率の高い適用先になります。

テストファーストとBDD・自動テストとTDDの役割の違いと境界

TDDは似た言葉と混同されやすく、混同したまま導入すると期待した効果が出ません。ここでは隣接する3つの概念との境界を引きます。

テストファーストとTDDの包含関係と実務での呼び分け判断基準

テストファーストは「実装より先にテストを書く」という順序だけを指す広い概念です。TDDはその一種で、さらに短いサイクルの反復とリファクタリングを手順として組み込んだものです。つまりテストファーストはTDDを含みますが、逆は成り立ちません。実務上の違いが出るのは粒度です。仕様書からテスト項目を全部書き出してから実装に入る進め方もテストファーストですが、これはTDDではありません。全件を先に書くと、実装中に判明した仕様の誤りがテスト側の大量修正へ跳ね返ります。数分単位で赤と緑を往復するかどうかが、呼び分けの実質的な線になります。

BDDとの違いを仕様の記述者と粒度から整理する実務上の判断基準

BDD（振る舞い駆動開発）は、テストを自然言語に近い形で書き、開発者以外も仕様を読めるようにする手法です。TDDのテストは開発者が読むためのもので、対象はメソッドやクラスの単位になります。BDDのシナリオは利用者の振る舞いの単位で、Given・When・Then の形をとります。両者は排他ではなく、外側の受け入れ条件をBDDで、内側のロジックをTDDで固めるのが実務的な組み合わせです。導入して割に合う条件と、Gherkin記法の維持コストについてはBDDとは？振る舞い駆動開発の仕組みとTDDとの違いで整理しました。非エンジニアがシナリオを読まない現場では、BDDの記述形式は維持コストだけが残ります。

単体テストと結合テストの粒度からみたTDDの守備範囲と境界線

TDDのサイクルが回るのは、実行が速く外部依存の無いテストです。1件の実行に数秒かかると、数分で赤緑を往復する前提を維持できません。したがってTDDの主戦場は関数・メソッド単位のテストで、データベースや外部APIを実際に叩く結合テストは別枠で管理します。目安として、サイクル内で回すテスト群は全件で数秒以内に終わる範囲へ保ちます。結合テストや画面のテストはCI側で実行し、手元では走らせません。この線引きが曖昧だと、テストの遅さが理由でサイクルそのものが放棄されます。

自動テストとCIの役割分担から分けるTDDが担わない対象領域

自動テストがあることと、TDDを実践していることは別です。実装後にテストを書いても自動テストは揃いますし、カバレッジも上がります。TDDが追加で与えるのは、テストしにくい設計が実装前に露呈するという副作用です。逆にTDDが担わない領域もはっきりしています。性能要件、同時実行時の競合、本番データ特有の異常値、画面の見た目は、単体のテストでは守れません。ここはCI上の負荷テストや実データを使った検証で受けます。TDDを入れたから他のテスト工程を削れる、という置き換え関係にはありません。

TDD導入が設計品質と保守コストに効く理由と限界の見極め方針

メリットとデメリットは同量で並べても判断材料になりません。実務での重み付けを付けて整理します。効果として最も大きいのは手戻りの圧縮で、コストとして最も痛いのはテストの保守です。

手戻りコストの圧縮という効果が出る条件と出ない条件の実務判断軸

不具合の修正コストは、発見が遅いほど膨らむ傾向です。実装直後に見つかれば数分で直りますが、結合テストで見つかれば原因箇所の切り分けから始まり、リリース後なら調査・修正・再テスト・顧客への説明までが加わるためです。TDDはこの発見時点を実装の瞬間まで前倒しします。ただし条件があります。前倒しできるのは「仕様と実装のずれ」と「境界値の抜け」に限られ、そもそも仕様自体が誤っている場合は前倒しできません。要件定義が固まらないまま着手した案件では、赤いテストごと作り直しになります。効果が出るのは、仕様の粒度が関数単位まで落ちている状態です。

テストコードが仕様書として機能するための具体的な記述方法と例

テストが仕様書として読まれるかどうかは、書き方で決まります。読まれるテストの条件は3つです。テスト名が条件と期待結果を述べていること、1件のテストが1つの条件しか検証していないこと、テスト内に条件分岐やループが無いこと。逆に、共通のセットアップへ大量の前提を押し込んだテストは、読んでも何が保証されているのか分かりません。Javaならテストの表示名を指定するアノテーションで、Pythonならテスト関数名そのもので条件を述べます。新規参加者が最初に読むのは仕様書ではなくテストである、という前提で書くと精度が上がります。

工数増と学習コストの実像から測る初期に遅れる期間の判断の目安

正直に言うと、最初は遅くなります。テストコードは実装と同量から2倍程度の行数になり、書き慣れるまでは1機能あたりの所要時間が伸びます。習熟の遅れは、経験者のレビューが付く体制なら数週間、独学なら数か月単位です。ここを「品質のための投資」と抽象的に説明しても社内では通りません。回収の説明は具体的にします。過去の不具合チケットのうち、単体レベルで検出できたはずのものが何件あったか、その調査工数の合計はいくらか。この2つを出せば前払い分との比較ができます。数字が出せない場合は、対象を1モジュールに絞って比較データを作るところから始めます。

モック濫用と過剰テストで保守が破綻する典型パターンと対策の例

失敗の大半はテストの作り過ぎです。典型は3つあります。1つ目は、内部実装の呼び出し順序までモックで検証してしまい、リファクタリングのたびにテストが壊れるパターン。2つ目は、単純な値の取得や設定のような自明なコードにまでテストを書き、本数だけが増えるパターン。3つ目は、テストが壊れたときに原因を調べず期待値を書き換えて緑に戻すパターンです。3つ目が最も危険で、テストが仕様の記録という役割を失います。対策は、壊れたテストの期待値変更をレビュー必須にすることと、検証対象を戻り値と副作用に限り、呼び出し回数の検証を例外扱いにすることです。

テストを後工程に置く進め方との比較でみた実務上の具体的な差分

従来型の工程では、テストは実装が終わった後の検査です。この順序でも品質は担保できますが、検出の遅れと設計への影響力の差が出ます。両者の違いを整理します。

観点	テスト後置	TDD
仕様の確定時点	設計書の作成時	テスト記述時
不具合の検出時点	テスト工程	実装の直後
設計への影響	ほぼ無い	疎結合へ寄る
初期の所要工数	小さい	大きい
向く案件	仕様固定の短期	長期保守の案件

この表は優劣ではなく適用条件の違いを示すものです。仕様が凍結され、リリース後の変更がほぼ無い案件では、後置のほうが総コストは小さくなります。判断は案件の寿命で分けます。

Red・Green・Refactorを実コードで回す手順と粒度の決め方

手順を具体例で追います。ここでは言語を問わない考え方を、JavaとPythonで書く場合の差に触れながら示します。コードの分量よりも、どこで止めてどこへ進むかの判断が要点です。

税込計算の例で追うRedからGreenまでの最小手順と判断軸

題材は「税込金額を返す関数」にします。最初のテストは、税率10パーセントで100円を渡すと110を返すこと、という1件だけです。関数がまだ無い状態で書くのでコンパイルが通らず、これがRedです。次に、110 を返すだけの実装を書いて緑にします。ここで「税率を引数にすべきだ」と考えて先に一般化しないのが要点です。2件目のテストとして、税率8パーセントで100円なら108を返すことを追加すると、定数返しでは通らなくなります。この時点で初めて計算式へ一般化します。テストが実装を引き出す、という順序を体感できるのはこの往復です。

分岐と例外を含むロジックで境界値を漏れなく洗い出す具体的方法

分岐が入ると、テストの設計そのものが本題になります。税込計算なら、端数処理の方式（切り捨て・四捨五入）、負の金額、ゼロ、上限値、税率が未設定の場合が候補です。洗い出しの手順は、まず正常系を1件通し、次に境界の両側を1組ずつ足し、最後に異常系で投げる例外の型とメッセージを固定します。例外のテストでは、例外が出ることだけを検証して型を確認しないケースが多く、これは検証として弱いままです。異常系を後回しにすると、実装側で例外設計が場当たりになり、呼び出し側のエラーハンドリングが分散します。

外部APIとデータベースをテストダブルで切り離す具体的設計方法

外部依存があるコードをサイクル内で回すには、依存を差し替え可能にする設計が前提です。手段は依存性の注入で、本番では実装を、テストでは代替物を渡します。代替物は一枚岩ではなく、返り値だけを固定するスタブ、呼び出しを記録するモック、簡易実装で置き換えるフェイクなどに分かれ、使い分けを誤るとテストが壊れやすくなります。テストダブル（TestDouble）とは｜5分類の違いと使い分けで5分類の判断基準を整理しているので、モックを書く前に自分が必要なのはどれかを確認してください。原則として、検証したいのが戻り値ならスタブで足り、モックは副作用の確認に限ります。

リファクタリングを挟むタイミングとコードスメルを見抜く判断目安

整える工程は、緑になった直後に入れます。次のテストを書き始めてから戻るのは避けます。判断の目安は、コードを読んで引っかかる箇所があるかどうかです。同じ条件式が2箇所以上に現れた、メソッドが画面1つに収まらない長さになった、引数が4つを超えた、コメントで補わないと意図が伝わらない。この4つのどれかが出た箇所は、その場で直す対象です。大きな構造変更が必要な場合は一度に行わず、テストが緑である状態を保ったまま小さな変更を重ねます。緑を保てない変更に踏み込むときは、変更前に対象範囲のテストを増やしてから着手します。

やることの一覧を作り一度に一つの関心へ絞る具体的な実践の方法

実務で最も効くのは、着手前にテストしたい項目を箇条書きで並べる習慣です。税込計算なら、正常系、端数処理、負値、税率未設定、上限超過、といった具合に列挙します。書き出したあとは上から1件ずつ赤緑を往復し、途中で思いついた項目は一覧の末尾へ足すだけにして実装には手を付けません。この分離があると、割り込みで作業が中断しても復帰点が明確です。コミットの粒度もこの一覧に合わせ、1件通してリファクタリングまで終えたところで区切ります。粒度が大きいコミットは、原因の切り分け時に差分が読めなくなります。

JUnit 6系とpytest 9系で組むテスト基盤と選定の判断軸

道具の選定でサイクルの速度が決まります。ここでは主要フレームワークの現行世代と、その周辺で必要になるものを実務の判断軸で並べます。版番号は執筆時点の一次情報にもとづく非断定表記です。

JUnit 6系のJava要件と5系から移行するときの確認点

Javaの標準的な選択はJUnitです。公式ユーザーガイドの現行版は6.1系で、実行時に Java 17 以上を要求します（2026年8月時点）。5系のまま止まっているプロジェクトが移行する場合、確認するのは実行環境のJavaバージョン、ビルドツール側のプラグイン対応、そして旧世代のテストを動かすための互換モジュールの扱いです。アノテーションやアサーションの書き方は5系の作法が概ねそのまま通るため、書き換え量よりも環境要件の確認が主な作業になります。基本的な書き方とテストクラスの構成はJUnitとは？Javaの単体テストフレームワークの基本と書き方で扱っています。

pytest 9系のfixtureとパラメータ化を選ぶ判断基準

Pythonでは標準ライブラリの unittest より pytest を選ぶ場面が多く、PyPI上の最新は9.1系です（2026年8月時点）。TDDの回転数に直結する機能は2つあります。前提の準備を関数として切り出す fixture と、同じ検証を入力値の組で繰り返す parametrize です。境界値のテストは後者で書くと、テスト関数が増えずに検証の網が広がります。注意点は fixture のスコープです。セッション単位で共有した状態をテストが書き換えると、実行順によって結果が変わるテストになります。既定の関数スコープから外す場合は、共有対象が読み取り専用かを確認してください。導入からfixtureの書き方まではpytestの使い方・書き方を徹底解説にまとめています。

モックライブラリの選定基準と静的メソッドを扱う際の実務注意点

Javaでは Mockito、Pythonでは標準の unittest.mock が既定の選択になります。判断が必要になるのは、静的メソッドやコンストラクタを差し替えたい場面です。差し替えたい対象が静的メソッドなら、まず設計を疑ってください。静的メソッドへの直接依存は、そもそもテストしにくい構造の兆候だからです。ラッパーを挟んで注入可能にすれば、特殊なモック機能は不要です。それでも既存コードに手を入れられない場合に限り、静的モックの機能を使います。この判断を曖昧にしたまま特殊なモックを常用すると、テストがコードの内部構造に固定され、リファクタリングのたびに壊れます。

カバレッジ測定の読み方と数値目標に固執した場合の具体的危険性

カバレッジ測定はJavaならJaCoCo、Pythonなら coverage.py が定番です。ただし数値を目標にした瞬間に、この指標は壊れます。アサーションの無いテストでもカバレッジは上がるためです。読み方を変えます。全体の率ではなく、直近3か月に変更が入ったファイルの未通過行を見る。ここに分岐の抜けが残っているなら、それは実際に危ないコードです。全体率を90パーセントへ引き上げる作業より、変更頻度の高い箇所の未通過行を潰す作業のほうが不具合の減り方に直結します。率を社内目標にするなら、下限の警戒線として使い、達成度の評価には使わない運用が現実的です。

CI/CDへ組み込んでグリーン維持を仕組みで強制する運用方法

手元で緑になることと、いつでも緑に戻せることは同じではありません。プッシュとプルリクエストの時点でテストを自動実行し、赤い状態をマージできない設定にして初めて、テストは仕様の記録として維持できるようになります。実行時間が長くなってきたら、サイクル内で回す速いテスト群と、CIだけで回す遅いテスト群の二群に分ける運用です。前者は数秒、後者は10分程度を目安に区切ると継続しやすい構成です。静的解析をあわせて回すと、テストでは拾えない未使用変数や潜在的な null 参照も同じ関門で止まります。仕組みで強制しない限り、忙しい週にテストは止まります。

テストの無いレガシーコードへ段階導入する順序とチーム定着の条件

既存プロジェクトへの導入が、実務で最も難しい局面です。テストが1本も無く、依存が絡み合い、仕様書が現存しないコードにどう手を付けるか。順序を間違えると1週間で止まります。

テストの無い既存コードで着手点を決める具体的な判断の優先順位

全体にテストを敷こうとすると必ず失敗します。着手点は3つの条件で絞ります。変更依頼が繰り返し来ている箇所、不具合の再発が起きている箇所、そして金額や在庫のように誤りの影響が大きい箇所。この積集合にあるモジュールを1つ選び、そこだけに集中します。逆に、5年間変更が入っていないコードにテストを足す作業は、投資として回収できません。既存システムの保守と内製化の体制づくりを外部と組んで進める場合は、保守運用・内製化支援のように、テストの整備とドキュメントの再生成を保守の工程へ組み込む進め方が取れます。着手範囲を先に契約で区切ると、範囲の膨張を防げます。

特徴記述テストで現状の振る舞いを変更前に固定する具体的な手順

仕様書が無いコードでは、正しい振る舞いが不明です。ここで書くのは「正しさ」のテストではなく、現状の振る舞いをそのまま記録するテストです。特徴記述テスト（Characterization Test）と呼ばれます。手順は、対象関数に代表的な入力を通し、返ってきた値をそのまま期待値として固定します。不合理な結果が出ても、その時点では直しません。まず現状を凍結し、変更の前後で差分が出ないことを確認できる状態を作ります。凍結が済んだあとで、その振る舞いが仕様として妥当かを担当者と確認し、直すべきものだけをテストの修正とセットで直します。この順序を守らないと、修正と改修が混ざって原因の切り分けができません。

新規機能だけテストファーストにする対象境界線の具体的な引き方

既存コードの全面テスト化は目標から外します。代わりに境界線を引きます。新しく追加するクラスと関数は必ずテストから書く。既存コードは、触るときだけその周辺にテストを足す。この2つが運用ルールの基準になります。既存の巨大なクラスに新しい処理を足す場合は、新しい処理を別クラスへ切り出し、既存側の役割は呼び出しだけです。切り出した側はテストから書けるため、テストされた領域を変更のたびに少しずつ広げる設計です。数か月続けると、変更頻度の高い部分にだけテストが集まった状態になります。全体率としては低い数字ですが、実務上の守りとしては十分に機能します。

ペアプログラミングとレビューでテストの書き方を揃える実践方法

個人技として導入すると、書き方が人ごとに散らばります。テスト名の付け方、モックの範囲、1テストの検証数がばらつくと、他人のテストが読めなくなり保守されません。揃える手段は2つです。ひとつは2人で同じ画面を見ながら赤緑を往復する進め方で、テスト設計の勘所がその場で伝わります。進め方と適した場面はペアプログラミングとは？メリット・進め方・ツールと導入判断で整理しました。もうひとつはレビュー観点にテストを明示的に入れることです。実装だけを見てテストを読み飛ばすレビューが続くと、テストの品質は下がり続けます。

TDDが定着しない場合に見直す具体的な運用ルールと計測の指標

数か月で元に戻る現場には共通点があります。忙しい時期にテストを省く例外を認めた、赤いままマージできる状態を残した、テストの保守を誰の担当でもない作業にした。この3つです。立て直すときは、精神論ではなく仕組みを直します。赤い状態でマージできない設定にする。テストの修正を含まない不具合修正をレビューで差し戻す。そして計測は本数やカバレッジ率ではなく、同じ原因の不具合が再発した件数で見るべきです。再発が減っていれば効いています。減っていないなら、テストを書く場所が実際の危険箇所とずれています。

生成AIがコードの初稿を書く前提で見直すTDDの費用対効果と適用の線引き

ここは競合記事がほとんど扱っていない論点です。コード生成AIが実装の初稿を書く前提に立つと、TDDの費用構造は変わります。結論から言えば、テストを先に書く価値は上がり、テストを人が書く価値も上がります。

AI生成コードの受け入れ基準としてテストを先に置く具体的手順

生成されたコードの問題は、動くように見えることです。読んで妥当そうに見えるコードが、境界値や例外系で崩れる。この検証を目視レビューだけで担保するのは無理があります。順序を固定します。人がテストを書いて仕様を確定し、そのテストを通す実装を生成させ、テストで受け入れる。この形にすると、生成物の合否判定が機械的に決まります。逆にやってはいけないのは、実装を生成させてからテストも生成させる進め方です。生成された実装の挙動をそのまま写したテストができあがり、仕様との差を検出できません。テストは仕様側の資産であり、実装の写しにしてはいけません。

仕様駆動開発との棲み分けとTDDが担う層を切り分ける判断基準

仕様を先に文書として固定し、そこから実装を生成させる進め方は、仕様駆動開発として整理が進んでいます。仕様駆動開発（SDD）とは？従来手法との違いで扱っている通り、こちらが担うのは機能単位・画面単位の外側の仕様です。TDDが担うのは、関数やクラスの内側の振る舞いです。両者は競合しません。外側の仕様を文書で固定し、内側の振る舞いを実行可能なテストで固定する、という二層構成になります。切り分けの目安は、その記述が自動で合否判定できるかどうかです。判定できるならテストへ、できないなら文書へ置きます。

TDDを採用しないと判断する三つの具体的な条件と実務での見極め方

採用しない判断も明確にします。第一に、外部仕様が固まっておらず、画面や項目が週単位で入れ替わる探索段階の開発。ここでテストを先に書くと、書き直し工数が実装工数を上回ります。第二に、成果物を数週間で破棄する検証用コード。回収期間が来ないため前払いが損になります。第三に、既存コードが単体で呼び出せない構造で、依存の切り離しに大規模な改修が必要な場合。この状況では、TDDの導入より先に依存の整理そのものを案件として立てるべきで、テストを足す作業から始めると改修と混ざって収束しません。この3条件に当てはまるなら、結合テストと動作確認で受け、TDDは見送ります。

よくある質問

TDDとは何かを調べる過程で実際によく出てくる質問を、判断に使える粒度で答えます。

TDDとは何の略で、どういう意味ですか？

TDDは Test-Driven Development の略で、日本語では「テスト駆動開発」と呼びます。意味は、実装より先にテストコードを書き、そのテストを通す最小限の実装を足し、最後に挙動を変えずに内部構造を整える、という3工程を短い周期で繰り返す開発手法です。テストを増やす取り組みと誤解されがちですが、実質はテストという形で仕様を先に確定させる設計手法です。テストは結果として残る副産物と捉えたほうが、導入時の判断を誤りません。

TDDとテストファーストの違いは何ですか？

テストファーストは「テストを実装より先に書く」という順序だけを指す広い概念で、TDDはその一種です。違いが出るのは粒度と反復の速さです。仕様書からテスト項目を全部書き出してから実装に入る進め方もテストファーストに含まれますが、TDDでは1件のテストを赤にして通し、整えるまでを数分単位で往復します。この短い反復とリファクタリング工程が手順に含まれるかどうかが、両者を分ける線になります。

TDDのサイクルは1周どのくらいの時間が目安ですか？

目安は数分から10分程度です。1周に1時間かかっている場合、テストの粒度が大きすぎるか、テストの実行自体が遅いかのどちらかです。粒度が原因なら、検証したい条件を1件に絞り直します。実行速度が原因なら、データベースや外部APIへの実接続がサイクル内に入っていないかを確認してください。サイクル内のテスト群が全件で数秒以内に終わる状態なら、往復の習慣は維持されます。

TDDを導入するとテストカバレッジは何パーセント必要ですか？

目標値を決める運用そのものをおすすめしません。アサーションの無いテストでもカバレッジは上がるため、率を目標にすると数字だけが動きます。見るべきは、直近で変更が入ったファイルの未通過行です。そこに分岐の抜けが残っているなら実害があります。率を使うなら、下限の警戒線として設定し、評価指標には使わない運用にしてください。全体率の引き上げ作業より、変更頻度の高い箇所の抜けを潰す作業のほうが不具合の減少へ直結します。

レガシーシステムにTDDを後から導入できますか？

できますが、全面適用までは行いません。手順は、変更依頼が繰り返し来ているモジュールを1つ選び、現状の振る舞いをそのまま固定する特徴記述テストを置き、以降その周辺を触るときだけテストファーストにする、という局所導入です。新規に追加するクラスは既存の巨大クラスへ足さず、別クラスへ切り出してテストから書く対象です。数か月続けると、変更頻度の高い領域にテストが集まります。全体率は低くても、実務上の守りとしては機能します。