テスト駆動開発（TDD）の事例 - IBMとMS 計4プロジェクトを紹介した論文 -
TDDに関する報告（論文）を読まなければならないと思いながら、読めていなかった。日曜日にその機会があったので読んだついでにメモっておくことにした。たまたま、月曜日にTwitter上でTDDに関する議論が盛り上がっていたのでタイムリーでびっくりしたが。。。
読んだ論文は次のとおり。Journal of Empirical Software Engineeringは論文誌としては、採択基準が厳しい部類に入る。
MS ResearchのWebから全文がPDFで読める。
TDD Boot campを紹介するエントリでも本論文を紹介されているので、参考にしていただきたい。
示されている定量データのうち私が気にかかったのは以下のとおり。
| 定量データ（メトリクス） | IBM Driver | MS Windows | MS MSN | MS Visual Studio |
| ソースコードサイズ(KLOC) | 41.0 | 6.0 | 26.0 | 155.2 |
| テストコードサイズ(KLOC) | 28.5 | 4.0 | 23.2 | 60.3 |
| TDDを採用していない類似プロジェクトでの欠陥密度を1としたときの欠陥密度 | 0.61 | 0.38 | 0.24 | 0.09 |
| TDD採用により増加したコード実装時間（管理者の見積りによる）* | 15～20% | 25～35% | 15% | 25～20% |
*はbiac氏のご指摘により「TDD採用により増加した工数」から修正した。
欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。
また、次のような知見が紹介されている。
- 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき（既存のソフトウェアの次バージョンから始める場合には言及がない）
- テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。
- テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。
- 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。
どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数が2割増しと見積られている。また、不具合密度が9～61%まで低減したことも述べられている。工数は見積りであり、不具合密度は同一のソフトウェアを比較したわけではないので、議論の余地はある）。
論文で紹介されているテストコードの比率を考えると、テストコードのメンテナンスのコストもそれなりに必要になりそうだ。
上述のようなデータが公開されていることは、これからTDDを、と考える方には貴重なものとなり得るだろう。テスト駆動開発のメリットは拡張性、保守性、可読性を（デグレードのことをあまり気にせず）高められることにもある。このあたりを評価できるようになると、TDDが適している開発、そうでない開発がもっと明確になり、自身のプロジェクトで採用するかどうか判断しやすくなるだろう。それはそんなに遠くない未来ではないように感じている。