TDD.NET

最初のセッションは、 和田卓人さん。 TDD の入門編。

和田さんのセッションの後半は、 参加者全員で TDD でした。 お題は FizzBuzz。

左手前に写ってるノートは、 私の EeePC。 VS2010beta2J と TFS2010beta2J を動かしてました。

次は、 Lasse Koskela さんのセッション。

ちなみに、 ここに写っているスライドの "Quality vs. Time" のデータは、 Empirical Software Engineering という雑誌の 2008年 6月号に掲載された論文 "Realizing quality improvement through test driven development: results and experiences of four industrial teams" からの引用です。 この論文は、 Microsoft と IBM とノースカロライナ州立大学が協力して書かれたものです。 Microsoft のサイトに全文が掲載されていますので、 英語が苦手でない方はぜひご覧ください。
4つのプロジェクトのデータが分析されていて、 グラフの左から、 IBM (Drivers / Java)、 MS (Windows / C/C++)、 MS (MSN / C++/C#)、 MS(VS / C#) です。("Windows" は、 全体ではなくてごく一部分。 Network のライブラリらしいです。)
同じ会社の、 TDD していない組織のデータとの比較で、 欠陥発生率は大幅に下がっています。 (緑のグラフ)
左から、 0.61倍, 0.38倍, 0.24倍, 0.09倍
しかし、 コーディングの工数 (正確のために論文の表現を引用すると "Increase in time taken to code the feature because of TDD (%) [Management estimates]") は増えています。 (オレンジのグラフ)
左から、 +15～20%, +25～35%, +15%, +25～20%
※ (2010/02/16 追記) この論文について、 森崎修司氏がブログに記事を書かれています。 ⇒ 森崎修司の「どうやってはかるの？」: テスト駆動開発（TDD）の事例 - IBMとMS 計4プロジェクトを紹介した論文 -
なお、 氏の記事では不明瞭というか開発全体の工数が TDD によって増加したとも読めるのですが、 原文は "time taken to code the feature" と書いてあるので、 実装の工数だけを比較しているのだと思います。

TDD の各ステップをクルクル回す話で、 1. Test - 2. Code - 3. Refactor の前に (0. Think) が書いてあって、 我が意を得たりと思わずニヤリ。
Lasse さんのお話、 前半は 「レガシーコード改善ガイド」 みたいな、 レガシーコードに対して TDD を持ち込むテクニックで締めて、 後半はライブでその実践でした。

最後の写真は、 セッションのときではなくて、 午後のペアプロが終わった後で、 みんなと同じ条件で Lasse さんが TDD したコードをレビューしてるときの様子。

ほとんどの参加者が前に座り込んで真剣にコードを見ています。
演台から向こうの部屋の半分は中継禁止エリアなので、 なぜか人物はボケちゃってます。 (いや、 私が画像処理してボカしたんですけどね。)

とても楽しいイベントでした。 主催側は不慣れだと言ってましたが、スケジュールや参加者への依頼事項などの事前連絡がちょっとマズかった以外は、 運営も上手く出来てたと思います。 この場を借りて、 運営スタッフの皆さんにもお礼を申し上げます。 ありがとうございました。

参加された多くの人が、 「TDD とは、 (すでに仕様が決まってるモノの) テストを考えることじゃなくて、 メソッドレベルの (まだ仕様が決まっていない) 外部設計 (和田さんの言う「何を作るか」) を考えることなんだ」 ということを体感してくれてたら嬉しいなぁ。