もくもく会＠ディノ20080916 終了

Event

今回は8名の方に参加していただきました。そして今回はちょっと趣向を変えて最初の1時間は議論タイムとさせていただきました。

2日前のブログに次のトラックバックいただきました。

今ひとつTDDとかBDDに対して懐疑的とゆーか今ひとつよく分からない。 - ぐらめぬ・ぜぷつぇんのはてダ

これは答えねばなるまいとは思っていたんですが、なかなか考えがまとまらない状態でもくもく会に参加いただくことになったので、そこでディベートをさせていただこうということに。
私の方で以下のような論点かなぁということで絞って話をさせてもらいました。

TDDのテストって？
まぁプロセスはウォーターフォールだろうがなんだろうがいいですが、「要件定義」「外部設計」「内部設計」「コーディング」「単体テスト」「結合テスト」「QAテスト」「受け入れテスト」ということを考えたときにTDDは「コーディング/単体テスト」のスコープにあたると思ってます。で、今まで単体テストは後から行うことになってたのを前にやってしまおうという方法論です。なので、実質工数は増えてません。ここで手間が増えたと主張される方がいれば、その人は単体テストをしてなかったということになります。ただし問題なのは、TDDはXPから生まれたものなので、厳密に言えば「要件定義」から「結合テスト」まではもう一塊で進んでいって、しかもイテレーティブです。そのあたりの感覚は数ヶ月かけてウォーターフォールをするという感覚とは合致しないところがあるかもしれなくて、TDDがなかなか肌感覚として合わないのはそのせいでは？というのも出ましたね。これも楽しい発見。
UnitTestの範囲は？
超原理主義的には1つのクラスですね。他のクラスを使うとか他のクラスに依存していて、それらの実クラスを使ったらもう単体ではないですね。これもいろいろ流派があるっぽく、微妙なんですが。少なくともプレゼンテーション層のもの(RequestオブジェクトやResponseオブジェクト、Sessionオブジェクト等)やリソース層(データベースやファイルやOSのシステムコール等)を直接呼んじゃったらもう単体ではないかと思われます。そのあたりはモックにすべしというのが単体テストだと思います。まぁ、チームメンバーが作ったクラス同志のコラボレーションぐらいは単体テストとみていいか？という流れもあるようです。このあたりの話を熱く議論したい方は是非Working Effectively With Legacy Code読書会に参戦下さい。
自動化の意義
SeleniumでUIのテストがどこまでできるのか？という話が出てましたが、本当の見栄えのテストはできないと思います(現時点では)。左にきっちり納まっているべきものがなんかずれてるとかというテストは出来ないでしょうね。そういうのが出来ないから自動化しても意味ないんでは？といわれても、別の理由で自動化すべきだと思ってます。自動化すると一部ではなく全部を毎回テストできます。自動化してないと「影響範囲だけテストしようか」というような中途半端な事が起きて、バグが残ったりします。また、UnitTestレベルで言えば、何かしくじるとどこかのテストがRedになるわけです。それを逆手に取れば、グリーンであればやりたい放題思い切ったリファクタリングが出来るわけです。私たちはテストをする事が目的ではなく、お客様に「動作するきれいなコード｣を提供するのがゴールです。そのためには自動化されたUnitTestが不可欠だと私は思ってます。
開発段階だけではなくて、保守フェーズでも無駄にならないのか？
この項目は反論の余地がありません。ファウラーですら、納品後のコードを久々に引き取ったらテストがレッドだったという経験をしてるわけであり、保守フェースの担当者に単体テストの資産価値を十分理解してもらう必要があるんだと思います。
TDDとはテストではなく設計っていうけどほんと？
これもやっぱり誤解を生んでるみたいな感じ。TDDの設計は私にとっては「メソッド名」「引数」「返却値」を決める程度の作業です。が、これは十分設計です。要はインタフェース設計ってことですね。プロジェクトにアーキテクトがいるとして、その人しか設計をしてないということではないんです。我々開発者も日々設計してるんですよ、小さい単位で。なので、TDDは設計手法ですというのは私はあってると思ってます。

あわせて前から言ってることを説明させてもらいました。日本人はほんとまじめです。20個プラクティスがあれば、全部守らないと思っちゃうんですよね。いいんですよ、1つでも取り入れそうだったら取り入れれば。その感覚があれば、気軽にTDDチックな開発ができると思いますよ。

まぁ、結構濃い話がでたので、この内容はOSC 2008 Tokyo/Fallの発表に盛り込みます。「コーディング/単体テスト」というレベルのテストを他人事だと思っている開発者はやっぱダメだと思うんですよ。我々のゴールは最終的には「お客様に品質の高いしかも良いソフトウェアを出来るだけ早く提供すること」ですよね。そのためには手間を惜しんでは行かんのですよ。我々はプロなんだから。