テストとモックとカバレッジ

技術

今のプロジェクトではモックをつかってユニットテストをしています。

モックはdjUnitのVirtual Mock Objectsをメインで使っているのですが、
これってテストメソッド毎に実行できないんですよね。。。

テストメソッド数が多い場合はこれは効率が悪い。
注目しているテストメソッド以外も実行されてしまうので結構待たされてしまいます。

またテストもかなり遅くなる気がします。
スペックのいいマシン上のHudsonで実行する場合でも3500個で５時間かかってました。
この時間はテストだけでなくコンパイルやカバレッジを取る時間も含まれていますが、
それにしてもおそい。

なんか今のプロジェクトではカバレッジをあげることが実装担当者の最終ゴールになっているような節があり、
結構無理してモックを使っているようです。なんだかなあ。

しかもカバレッジ１００％とかいう割には結合するとまずうまくいかない。
単体と結合では設定も違うし、全体としてどういう順番で処理が行われるのかわかっている人はいない。

結合してみてはじめてどう処理が進むのかがわかり、また仕様バグもわかってくるという現状。
大規模、他社モジュール含む、複雑なので１歩１歩進めるしかないわけだが、来週から全統合する。
コンパイル、デプロイ、起動で１週間過ぎると思うんだが、それでもコンパイルがままならなかった前回よりははるかにましだと思う。

ともあれ、最近思うことはテストをうまく回すには下記がいいんじゃないかなと思ってます。

・Hudsonを使う
今回初めて実戦投入したのですが、開発者、PMともに受けはいいです。昨日Hudsonのジョブで黄色（不安定ビルド）から青色（安定ビルド）に変わったときは拍手喝采でした。

・Antを使う
HudsonはMaven2用のプロジェクトタイプを用意していることからもMaven2との相性はいい。
とくに上流ビルドと下流ビルドを駆使するにはMaven2がいいだろう。
しかし実績、情報量の多さ、小回りが効くことからAntはやはりすばらしい。
ただしEclipseとの相性はそんなによくない。固まることもある。Eclipseはbuild.xmlエディタとして使うのがいいかも。
またDBのテーブルつくるのもAntでやってます。なんちゃって継続的データベースインテグレーション。

・DBUnitはちょっと微妙
Excelのテストデータづくりではまった。どっちかというとPOIの問題か。DMLのほうがいい気がする。

・Seasar2のSMART Deployを使う
AutoRegisterはわかりやすい反面遅くなってしまう。

・djUnitのVirtual Mock Objectsは使わない
Seasar2のモックインターセプターでいいんじゃないかな。
AOPかけられないクラスは無理してモックかける必要はない。
ユーティリティでも無い限りカバレッジ１００％を目指す必要はない。
djUnitでカバレッジとるのはいいかも

・テストはEclipseのプロジェクトをわける
DBアクセス含むテストと含まないテストもわけたほうがいいと思う。
今のプロジェクトではプロダクトコードもふくめて一緒になっている（ソースフォルダは分けている）ので、
DBアクセスを含まないテストなのにDBアクセス含むテストに依存してたりして、Antで実行するときにおもわぬコンパイルエラーに遭遇してしまった。

つまり

project/
  src/main/java
  src/test/java
  src/dbtest/java

じゃなくて

project/
  src/main/java

test-project/        projectに依存している
  src/test/java

dbtest-project/      projectに依存している
  src/dbtest/java

という感じで。