【誤解してた】「TDDは死んだ」の本当の意味と、現場でテストをどこまで書くか

「TDDは死んだ」の意味を解説する記事のアイキャッチ
claude
記事内に商品プロモーションを含む場合があります
【公開前に必ず削除してください】下書きメモ
・狙ったメインキーワード:TDDは死んだ(Search Console 直近28日:表示10回/表示日数9日/平均14.6位/クリック0)。既存記事「テスト駆動開発【要約・感想・まとめ】」が14位付近で拾っているものの、書評記事のため「この言葉の意味そのものを知りたい」という検索意図には正面から答えられていません。そこを取りに行く記事です。
・関連キーワード:テスト駆動開発/テストファースト/DHH/ユニットテスト
要確認1:DHHの原文(2014年)と、そのあとの Kent Beck・Martin Fowler との対談「Is TDD Dead?」に触れています。年号・固有名詞に間違いがないかご確認ください。
要確認2:本文の体験談は、既存記事「テスト駆動開発【要約・感想・まとめ】」で書かれていた「TDD=テストファーストだと思い込んでいた」という記述だけを根拠にしています。ちゅけさんご自身の現場での具体的なエピソード(どのプロジェクトで/どこまでテストを書いたか/やめた判断をした場面)を1つ足していただけると、この記事の強さが一段変わります。「現場でテストをどこまで書くか」の章に差し込むのがおすすめです。
要確認3:カバレッジや工数の具体的な数字はあえて入れていません。実数を書けるものがあれば追記してください。
・画像:アイキャッチ1枚(AI生成イラスト)+本文図解2枚(matplotlibで自作)。本文に写真を足すなら、実際のテストコードやCIの実行画面のスクリーンショットが最も効きます。
・内部リンク:テスト駆動開発の書評記事、レガシーコード改善ガイドの書評記事の2本。

「TDDは死んだ」という言葉を初めて見たとき、私は素直に「もうテストは書かなくていいのか」と受け取りました。これは完全な誤読でした。

この言葉はRuby on Railsの作者DHH(David Heinemeier Hansson)が2014年に公開したブログ記事のタイトルから広まったものですが、原題は「TDD is dead. Long live testing.」です。後半を訳せば「テストよ永遠なれ」。テストそのものを否定した文章ではありません。

私自身、『テスト駆動開発』(ケント・ベック著/和田卓人訳)を読むまでは、TDDとはテストファーストのことで、目的はバグを出さないことだと思い込んでいました。読み終わったあと、自分がこの言葉を一度も正しく理解していなかったことに気づきます。この記事では、その誤解がどこで生まれるのかと、現場でテストをどこまで書くかの考え方を整理します。

この記事でわかること
  • 「TDDは死んだ」が誰の、どういう文脈の言葉なのか
  • この言葉をめぐる4つのよくある誤解
  • TDDの本質が「テストの量」ではない理由
  • テストファーストとTDDはどこが違うのか
  • 現場でテストをどこまで書くかの判断軸
TDDのRed・Green・Refactorの3ステップを示した図
TDDはテストの量ではなく、この小さいサイクルの話
スポンサーリンク

「TDDは死んだ」は誰が、どういう文脈で言ったのか

冒頭のとおり、発言の主はRuby on Railsの作者であるDHHです。彼が問題にしたのは、「何があってもTDDでなければならない」という教条主義的な空気のほうでした。テストを書く行為ではなく、それを絶対的な作法として強制することへの批判です。

この記事は当時かなりの反響を呼び、DHH・ケント・ベック・マーティン・ファウラーの3人による「Is TDD Dead?」という対談シリーズにまで発展しました。賛否が割れたテーマだったからこそ、タイトルの一行だけが切り取られて広まってしまったというのが実際のところだと思います。

ちゅけ
ちゅけ

私も最初はタイトルしか見ていませんでした。「そうか、書かなくていいのか」と思った時点で完全に負けてます。

「TDDは死んだ」をめぐる4つの誤解

この言葉を目にした人がやりがちな読み違いを、実際の主張と並べて整理しました。

「TDDは死んだ」のよくある誤解と実際の主張を比較した図
左が誤解、右が実際に言われていること

左側はどれも「テストの否定」として読んだ場合の解釈です。ですが実際に議論されていたのは、テストを書くかどうかではなく「どの粒度で、どの順番で書くか」でした。ユニットテストに寄せすぎると、テストしやすくするためだけの不自然な分割が設計に入り込む。その副作用を指摘したのがDHHの論点です。

つまり「TDDは死んだ」を根拠にテストを書かない判断をするのは、主張を裏返して使っていることになります。元記事はむしろ、テストを残すために書かれた文章です。

TDDの本質は「テストの量」ではなく「サイクル」

『テスト駆動開発』を読んで一番驚いたのは、TDDのルールがたった2つしかないことでした。「自動化されたテストが失敗したときだけ、新しいコードを書く」「重複を除去する」。この2つだけです。

この2つを実際の手順に落とすと、先ほどの図のとおりRed(失敗するテストを書く)→ Green(通る最小限のコードを書く)→ Refactor(重複を消して設計を整える)という短いサイクルになります。カバレッジを100%に近づけることは、このルールのどこにも出てきません。

ちゅけ
ちゅけ

テストの本数を増やす作業だと思っていた時期が、私にもありました。

テストファーストとTDDは同じではない

ここが私の最大の勘違いでした。テストファーストは「テストを先に書く」という順番だけの話です。TDDはそこにリファクタリングが入り、設計そのものを継続的に見直すところまでを含みます。テストが通ったあとに手を止めてしまうなら、それはテストファーストであってTDDではありません。

日本語版の訳者である和田卓人さんが書き下ろした付録C「テスト駆動開発の現在」には、TDDの本質は結果(できあがったテストとコード)ではなくプロセス(思考とリファクタリング)にあると書かれています。この一文を先に読んでいれば、私は10年近く誤解せずに済んだはずです。

本そのものの内容や、付録Cの詳しい要約は【TDDは死んだ】テスト駆動開発【要約・感想・まとめ】にまとめています。

では現場でテストをどこまで書くか

ここからは本の話ではなく、実務の話です。「TDDは死んだ」の議論が実際に役立つのは、すべてをTDDでやろうとせず、効く場所を選んで使うという判断ができるようになる点にあります。

TDDを試す価値が高い場面
  • 入力と出力がはっきりしているロジック(計算・変換・判定)
  • 仕様が細かく決まっていて、変わりにくい部分
  • バグ修正のとき(再現するテストを先に書くと確実に潰せる)
  • 何度も仕様変更が入りそうで、壊れていないか毎回確かめたい箇所
  • 自分が設計に迷っていて、外側の使われ方から考えたいとき
無理に貫かなくていい場面
  • 画面まわりなど、仕様がまだ固まりきっていない箇所
  • 一度きりで捨てる調査用スクリプト
  • テストの下準備に本体の実装より何倍も時間がかかる箇所
  • チームで合意が取れていないのに、一人で先に強行するとき
  • カバレッジの数字を上げること自体が目的になっているとき

特に4つめは効きます。テストの書き方が揃っていないチームでTDDだけを持ち込むと、レビューで毎回もめて開発が止まります。まずは自分が担当するロジック部分で静かに試して、速くなった実感を持ってから共有するくらいがちょうどいいと感じています。

また、そもそもテストが1本もない既存コードに後からテストを入れる話は、TDDとは別の技術が必要になります。そちらは【脱却しよう】レガシーコード改善ガイド【要約・感想・まとめ】のほうが参考になるはずです。

まとめ

「TDDは死んだ」という言葉について、誤解しやすい点を整理しました。要点はこれだけです。

  • 発言の主はRuby on Railsの作者DHH。原題の後半は「Long live testing(テストよ永遠なれ)」
  • 批判の対象はテストではなく、TDDを絶対視する空気のほう
  • TDDのルールは「テストが失敗したときだけコードを書く」「重複を除去する」の2つだけ
  • テストファーストは順番の話、TDDはリファクタリングまで含めた設計の話
  • 全部をTDDでやる必要はない。効く場所を選んで使えばいい

この言葉は、テストをやめる理由ではなく、テストとの付き合い方を選び直すための言葉です。もし私と同じように「もう書かなくていいのか」と読んでしまっていたなら、次に手を入れるロジックひとつだけでいいので、テストから書いてみてください。3ステップを1周するだけで、言いたかったことの半分は体感できます。

本の内容そのものが気になった方は【TDDは死んだ】テスト駆動開発【要約・感想・まとめ】を、テストのない既存コードに悩んでいる方は【脱却しよう】レガシーコード改善ガイド【要約・感想・まとめ】もあわせてどうぞ。

スポンサーリンク
記事URLをコピーしました