djUnit
テストクラスを作ったはよいが、その後インターフェースに変更があったりするとテストされないメソッドがでてくる。
djUnitとは
djUnitは、ユニットテストを安全かつ、低コストで行うこと目的に開発されたTestRunnerで、Eclipseのプラグインとして動作します。
JUnitのTestRunnerで実行できるテストなら、そのままdjUnitで実行するとこができ、実行方法も従来のJUnitテストと同様です。
今回ダウンロードしたのはjp.co.dgic.eclipse.jdt.djunit_3.0_0.7.0.zip。
いつも通り解凍して、Eclipse配下に突っ込むだけだ。
Wikiを見ながらちょちょいと設定して（若干設定画面が異なるが気にしてはいけない）、ぽちっと実行する。
んーと、気がついたこと。
１．レポートの見方がよくわからない
テスト対象クラスだけではなく、関連した全てのクラスの網羅具合がでてくるので、肝心なところがちょっとわかり難いかな？
・・・それは仕方がないか。
・プロジェクトを選択してdjUnit実行（(テストクラスがないものはちゃんと網羅率０％・・・っぽい))
・テストクラスを選択して実行。
と二つの選択肢があるので、これは便利といえば便利。
"%line"は行*2ベースでの網羅率
"%branch"。これはなんだろう。・・・if文とかの網羅率ということか？
"coverfage""summary"の選択があるのだけど、表示一緒だな・・・。
あ、でもテスト対象のクラスを選択してチェックすればいいだけか。<=これが目的だし。
=>パッケージ単位でも出力できるので、ビジネスロジックのクラスは本当にそれだけでパッケージングした方がよさそうだね。
２．DbUnitを利用しているあたりが全滅
これはSpringなどの外だしにしたファイルを読み込むのに失敗している。
したがってdjUnitではテストが実行できないので網羅率０％がたたき出される。
使い方が悪いのかな？
Mockを利用しているビジネスロジックに関しては十分チェックはできそうだ。
ビジネスロジック層のテストが一番重要かつ変更も多いかつコードが多いのだしとりあえず入れてみるのも悪くはないはずだ。
DBアクセスを使うところはまた考えるとしよう。
djUnitはEclipseのプラグインなので、ビルドサーバでは当然利用できない。
その際は、JCoverageとやらを使うことになるのかな。
