テスト駆動開発の効果はどのくらいある？

ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。

この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。

開発時間はやや増えたがコードの品質は上がった

論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェアそのものについての影響を一部引用します（追記：こちらで全文読めるようです）。

• TDDを実施した場合に、コーディング（実装）の時間が16％増えた。
• TDDを実施した場合に機能テスト（ブラックボックス）で不具合を検出するテーストケース数が削減された（不具合を検出したテストケースが18%減少）。
  （追記：正確には「"they passed 18% more functional black-box test cases."」とありますので、TDDアリではパスしたテストケースの数が18%多かった、ということのようです）

開発時間はやや増えたけれども、コードの品質は上がったといえそうです。では、TDDについてプログラマはどう感じたのか。これも一部引用しましょう。

• 96％の被験者がデバッグの工数を減らすと感じた。
• 92％の被験者がコードの品質を上げると感じた。
• 88％の被験者が要求が洗練されると感じた。

ほぼ9割の開発が、コードの品質が高まりデバッグの工数も減ると同時に、要求も洗練されると感じたとのこと。最初にテストコードを書くことで要求についての理解が深まるのがTDDの大きな利点の1つですが、その利点が表れているように見えます。

と同時に、開発時間は前述のように16％増えたにもかかわらず、次のように感じたプログラマも半数いたとのこと。

• 50%の被験者が開発工数を減らすと感じた。

論文は「Boby George, a and Laurie Williams: A structured experiment of test-driven development, Journal of Information and Software Technology Vol. 46, No. 5, p. 337-342(2004)」です。

TDDはプロジェクトの開始時からやるべき

森崎氏は2月にもTDDに関する別の論文を、エントリ「テスト駆動開発（TDD）の事例 - IBMとMS 計4プロジェクトを紹介した論文 -」で取り上げています。

この論文では、IBMのデバイスドライバ開発チーム、マイクロソフトのWindows開発チーム、MSN開発チーム、Visual Studio開発チームが対象とされています。その結果は以下のようにまとめることができます。

• TDDの採用によりコード実装時間は約15％～30％程度増加
• 類似プロジェクトの欠陥密度を100とすると、TDDの採用により欠陥密度が9から61程度にまで減少

また、TDDはプロジェクトの途中で始めたり、途中でやめるとうまくいかず、プロジェクトの開始時からやるべき（ただし既存のソフトウェアの次バージョンから始める場合の言及はなし）、という導入のノウハウや、テストコードの実行速度に気を配り、速くテストを実行できるようにしないと、それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。といった注意点にも言及されています。

この結果からも、TDDはある程度コードの実装時間は増加するが混入する欠陥の数は減少する傾向にあることが読み取れるようです。

この論文は「N. Nagappan, M. E. Maximilien, T. Bhat and L. Williams: Realizing quality improvement through test driven development: results and experiences of four industrial teams, Journal of Empirical Software Engineering, vol. 13, pp. 289-302 (2008)」です。こちらは全文が読めます。

森崎氏は、こうした論文の意義について次のように書いています。

テスト駆動開発のメリットは拡張性、保守性、可読性を（デグレードのことをあまり気にせず）高められることにもある。このあたりを評価できるようになると、TDDが適している開発、そうでない開発がもっと明確になり、自身のプロジェクトで採用するかどうか判断しやすくなるだろう。それはそんなに遠くない未来ではないように感じている。

自分一人でも始められる

テスト駆動開発やテストファーストは、アジャイル開発手法のようにチームで取り組むものとは違い、自分一人でも開発現場で始めることができます。

先輩や上司から依頼された機能の実装、顧客から発注されたシステムの一部、そうした部分の開発を、要求仕様を見ながらテスト用フレームワークを使ってテストファーストで開発し始めることはきっとできるでしょう。

もしもここで紹介したようなテスト駆動開発に興味を持ったとしたら、そのようにして試してみるのはいかがでしょうか？ そしたら次はリファクタリングなんかできるようになっちゃうかもしれませんよ？