開発プロセス・方法論

テスト駆動開発

（てすとくどうかいはつ／Test-Driven Development）

登場（海外）: 1999年
更新: 2026-08-25

一言でいうと

先にテストを書き、それを通すコードを書いてから設計を整える進め方です。テストを書く習慣のことではなく、書く順序を決める手順を指します。

提唱者と登場年

Kent Beckが1990年代後半に、Extreme Programming（短い反復と自動テストを中心に据えた開発手法）の一部として確立しました。初出を1年に絞ることはできません。Extreme Programmingが始まったのが1999年で、Beck自身がこの手法について述べたのは2003年です。ここでは概念の起点として、Extreme Programmingが広まった1999年を採っています。

国内での普及時期は特定していません。現在では単体テストを書く習慣とほぼ同じ意味で使われることもあり、本来の手順を指しているとは限りません。

何を解決するか

後からテストを書くと、実装しやすい形に引きずられ、仕様を確認するテストになりません。先に書くことで、何ができれば正しいのかを実装前に決めます。

もうひとつの効果が設計への影響です。テストしやすい形を先に考えるため、依存関係が整理され、外部との結合が疎になりやすくなります。

実際の進み方

失敗するテストを書き、それを通す最小限のコードを書き、重複を取り除く。この3段階を小さく繰り返します。一度に扱う範囲を小さく保つことが前提で、大きな機能をまとめて扱うと成立しません。

テストの実行が遅いと循環が回りません。実行時間を保つ設計は、この手法を続けるための条件になります。

導入でよくある失敗

テストを後から書いて名前だけ借りる。設計への効果が得られません
実装の詳細に密着したテストを書く。リファクタリングのたびにテストが壊れます
全領域に適用しようとする。UIや外部連携では費用対効果が合わない場合があります

求人票にこの語がある場合に読み取れること

テストを書く文化があることは読み取れますが、手順まで守っているかはわかりません。単体テストの整備を指してこの語を使う組織も多くあります。

要件に入れると対象が狭まるうえ、経歴に明示する候補者も限られます。

自社側では、テストの実行時間と、テストを書く時間が見積もりに含まれているかを確認します。候補者には、テストを先に書く場面がどれくらいあったかを聞きます。網羅率の数字を聞いても実態はわかりません。

隣接手法との違い

用語	指すもの	この語との違い
単体テスト	部品単位で動作を確認するテスト	成果物の話。TDDは書く順序の話
シフトレフト	テストを工程の前方へ移す考え方	工程全体の設計。TDDは実装者の手順
ビヘイビア駆動開発	振る舞いを自然言語に近い形で記述する手法	記述の対象と表現が違う