JUnit実践入門の写経・実践会は#2に参加しての二回目。
前回は、1日で4章〜10章と一気に飛ばしたので内容豊富でした。
今回は11章のモック系のみ。前回とは全くスピード感が違っていました。
今回の対象は第11章 テストダブル、モックのような代役を立ててテストを行う話です。
議論としては、モックに関するもの、それ以外のものもいくつか出て楽しかったです。
今回は、あの@t_wada さんがドタ参してくれたので、いろんなトピックについて深い話を聞けました。
いくつか、トピックを書くと
privateメソッドはテストすべきか?
→ Groovyなら private メソッドでもテストできるよ(違う)。
→ 否。private メソッドはpublic メソッドのテストによりテストができるはずである。また、private メソッドについてテストをしなければならないほど複雑であると考えているなら、private メソッドの責務が多すぎて、分割すべきである。
これも、よく自分も聞いてしまう質問だけど、再認識した。
リファクタリングの効果を示した統計情報などはあるか?
→ リファクタリングをやった場合とやらない場合で比較をしなければならないので、大企業が実験的に実施した結果として出てくる事がある。そのような情報があったとしても、定量的に示すのは難しい。リファクタリングの効果としては、機能追加を行う・バグ修正を行う速度を落とさないようにできるということであるが、あくまでも間接的な価値であり、直接的な価値を生むものしか評価されにくい。なので、リファクタリング自体はあくまでもプログラミングの一環として工数を積むのがよいと思われる。
「リファクタリング工数」という言葉が出てきた時点で、ほぼ敗北は決定している…。
「リファクタリングした」なら言ってもいい!
生産性って?
→ ソフトウェアの行数はプログラミング言語の特性にも左右されるし、長ければ機能が実現されているというものでもない。それを生産性として価値を生み出す速度として定義するのは全く馬鹿げている。生産性という言葉を使うのであれば、個人として予定と実績を記録し、過去の自分よりどれだけできるようになったのか。ということくらいだろう。
依存クラスのテストまで含めたテストはUnitテストじゃないの?
→ 急進的モッキスト(モック主義者)は、Unitテストとはクラスを結合させないテストであり、別のクラスを呼び出している場合、結合した状態で試験をするのは結合テストであり、Unitテストではモックかスタブを使うべきであると、言われていますが、理想的な振る舞いをモックにさせてテストを行うとテストの安定性は高まるが、モックのコード量は増えるし、依存オブジェクトを含めた振る舞いの試験が後回しになってしまう。
Unitテストは基本的には十分速いテストのことであるが、振る舞いを確認できる範囲とテストの安定性のバランスを考える必要がある。
(議論の内容をあまり追えてないので適当に書いてるところが多いです(^^;)
Javaのモックライブラリとしては何がおすすめ?
→ 黒魔法なモックライブラリはあるが、mockit が実装機能のバランスがとれているところ、xUnit本に出てくるモック・スタブ・スパイとの用語の対応がとれたままうまく実装されているのでおすすめ。
さらに、和田さんの出現が確定した段階で、タネマキの管理人さんに『SQLアンチパターン』を買ってきていただいた上で、和田さんにサインをいただくイベントが発生しました。
読みます。そして勉強させていただきます。
勉強会後には、中華料理屋でご飯を食べました。
そこでも、いろいろ含蓄のある話を聞くことができました。
みなさま、楽しかったです。ありがとうございました。
そして、私も社内での発表がんばります。