昨日の豆ナイト テスト駆動開発 by 相馬さん

セミナー＋懇親会＋相馬さん２次会，と深夜3時近くまでふらふらしてました．そして，今朝撃沈．とまあそっちの話はおいといて．

講師をされた相馬さんは，ウォーターフォール型開発を数年間経験された後，RUPをさらに４年くらい経験されて，その上で開発リーダーとなった今はご自身の意思でTDDによる開発を行われておよそ１年間が経つ方です．

そういったこれまでの経験を踏まえてTDDについての講義が行われつつ，同時に「実際にTDDしているところを見てみましょう，そのほうが分かりやすい．」ということで，Stackを実装する例をTDDでやるという実演（３０分くらいで）をされました．

テスト駆動開発と言えば，あのケント・ベックさんの『テスト駆動開発入門』（日本語訳版あり）が原典として有名で，私も半年くらい前に一応読んではいます．

http://www.amazon.co.jp/exec/obidos/ASIN/4894717115/249-7566002-6209113

ただ私の場合には実践が伴ってはいなかったので，いまいち実感を持ってつかみきれていなかった部分があります．そこで昨日の相馬さんのTDD実演があったので，非常に理解が深まりました．

例えば，TDDでは実装クラスの設計などは行わずに，まず最初にテストメソッドを書きます．つまりその時点で，TestStackというテストクラスはあるのに，Stackというクラスは無いという状況になります．当然，Stackクラスが無い状態なのでTestStackクラスはコンパイルが通りません．

しかしTDDの特徴というのはここからで「コンパイルが通らなかった理由というのが，裏を返せばシステムの実装としてこれから行うべき部分に相当する」と考えて，「Stackクラスが無いのでコンパイルできません」とエラーが出たのを見て「じゃあStackクラスを作ろう」とするのです．

一瞬「何？」と思うかもしれないですが，システム開発の基本的な流れである「要求定義→設計→実装」というのがTDDでは，「要求定義に基づいてテストメソッドを書く→コンパイルエラーあるいはテストの実行エラーになる個所が次に必要な要素→それを実装」というサイクルに当てはまります．

そしてそれを細かく反復していくことで，必要十分な実装を得るところまで行おうというものです．

なんとなく私のイメージで言うと，探索アルゴリズムにはレコードを１つずつ見ていく「順次アクセス」や，大まかにざっくり大小比較を繰り返して目的のレコードへ到達する「二分探索法」だとかありますが，まさにTDDは二分探索法のイメージです．

最終的にみんなが欲しい実装へ，どういうやり方でアプローチするのが，もっとも早く到達できるのかということを考えた一つの答えがTDDなのではないかと思います．

相馬さんの話で最も印象的だったのは，昔と比べて非常にハイスペックなPCが現在は各開発者に割り当てられており，またEclipse等の無償のIDEも普及しており，コンパイルや回帰テストの実行コストが昔と比べると100倍とか1000倍とかの比で少なくなっている．そうした時代状況それぞれに最適な開発手法というのがあるべきだと思うけれども，そのように考えてみると，マシンリソースが乏しかった時代に最適であったウオーターフォールは現在は最適ではなく，TDDのような開発手法が最適となっているのではないか，という話です．

日ごろミドルウェアや言語に対して，時代背景などの影響も含めて分析を行っていただけに，なるほどと思うところがありました．