TDD.NET

TDDでは、導入後2ヶ月から4ヶ月は生産性が低下すると言われている（TDDの利点。 - T/O）。これの原因は何か、対策はあるのかは、世界で共通の課題となっている。

TDD に限らず、 今までと違うやりかたをし始めれば、 必ず生産性は落ちます。 その落ち込みの深さと期間 ( 積分した 「面積」 ですね ) を減らすにはどうしたらよいか、 というのは課題です。 ゼロにすることは不可能でしょう。

TDD を導入したとき、 慣れていないことによる低下分以上に生産性が低下するように見える現象を、 私も何回か経験しました。 その理由は、 大きく二つあると思います。
1. 生産性の計測方法の誤り
2. TDD に必要なスキルが不足していた

1. は、 いわゆる 「製造工程」 だけで生産性を測ることです。 実際には、 「製造工程」 で作りこんでしまう不具合数が減るので、 「結合テスト工程」 以降の工数が減るのですが、 そこまで含めて生産性を計測しないと、 非常に悪化したように見えてしまいます。

2. は、 ユニットテストを書くために必要となるスキルと、 リファクタリングをするために必要となるスキル。 リファクタリングは上手く出来なくてもコードは動くので、 生産性の話から外すと、 結局はユニットテストを書くためのスキルが無いので、 ユニットテストを書くことに慣れる以前に、 その習得に時間が掛かる、 ということになります。

それでは、 ユニットテストを書くために必要なスキルとは何なのか、 ですが、 そのひとつとして、 メソッドやクラスの外部設計を考える能力があるのではないか、 と私はこの頃思うようになりました。 ユニットテストをうまく書けない人に、 これから作ろうとしているメソッドの説明をしてもらうと、 メソッド内部でこうしてああして… ということはこと細かく説明できる ( メソッドの内部設計は出来る ) のですが、 そのメソッドがエラーを出す条件は、 とか、 DB に null が入っていたら何が返るのか、 といったメソッドの外部設計に関する質問をするととっさに答えられない、 ということを何回も経験したからです。

デモで、RedのはずがGreenになった。
    * 違うプロジェクトのクラスを参照してた？他のプロジェクトを閉じることで正常に「Red」に。

ときどきあるんですよね。 こういうこともあるから、 まず Red にするという原則をできるだけ守らなくてはいけません。 ( 実際は、 どうしても飛ばしがちになりますが… )

続いては、 別の人の書かれた blog ですが、 この勉強会の第2回。

眠るシーラカンスと新米プログラマー: TDD勉強会に参加してきました
2009年06月28日

・コードより日本語の方がわからない
　(結論)この本は難解だ！！
　もう一言あればいいのになぁ、とかこの文は何を言おうとしているのだろうと悩むことが多々。

ほんとにそうですよね。 最近の Kent Beck の著作は良くなってきているように思いますけれど。

Eclipse+Javaのリファクタリング機能のようにTDD開発のコストを下げてくれるものはあるけど、知らないだけという場合も多いので研鑽がもっと必要だぁ。

書かれていないだけで、 勉強会の中ではきっと話題になったと思いますけれど…
「自力で出来るようになってから、 機械に頼るようにしないとダメになるよ。」

リファクタリング機能が 100% 完璧であるなら、 自分が理解していなくてもいい、 とも言えるのでしょうが、 現実には、 完璧なリファクタリング機能は ( まだ ) 存在しないので。
リファクタリング機能が間違ったことをやるかもしれないし、 あるいは、 自分で微調整しないといけないかもしれないですよね。 なにより、 機械頼みでは、 新しいリファクタリング方法を発見できないし。

なお、 本 TDD.NET サイトとしては、 Java はスコープ外です。 「テスト駆動開発入門」 は Java メインでコードが示されています。 ですが、 C# や VB.NET に 「翻訳」 しながらこの本の内容を追いかけてみることは、 とてもよい勉強になると思います。 なんといっても、 TDD の発案者が書かれた本ですしね。