bon now

最近になってようやく、Java（しかもEJB）によるテスト自動化手法について改めて考える時間ができてきた。

結構ググってはみるものの、体系だった情報は日本語圏にはなかなか無い。 というのも、EJBの仕組み上、単体テストがしにくかったり、結合テストの自動化自体WAR・EARなどのデプロイ系 アプリではしにくいため、とっつきにくく実際やってる人も少ないからじゃないかと判断している。

例えば僕がよく使うSeamの場合、SeamTestというSeam製EJBのテスト用ラッパがあるんだけど、 それを使ったからといってJUnitやtestNGとかで簡単に単体テスト自動化ができるほど、 EJBは甘くない。
実際のところインジェクション、アウトジェクションなどのEJBの持つ強力なORMやCDIの利便性が、 テスト時は逆にモック・スタブの作成や前提定義の作り込み工数となってプロジェクトを圧迫することになる。 オブジェクト指向で作られなかった密なるクラスの塊ばかりだと、 本当に悲惨なことになる。(経験談)

というわけで、EJBアプリはTDD、BDDによる「テストのし易さ」および 「振る舞いの簡易な表し方」を主眼としたアプリ作りの手法が向いてるんだと思う。 意外だと思う人もいるかもしれないけど、やってみたらわかる。多分。

そういう考え方が自分の中で固まってくる中、僕が今やってみようと思っているのは、 めんどくさい単体テスト自動化ではなく、 (もはや後付でのテスト開発は無用な工数が嵩むだけなので) 今後インテグレーションしていく中で繰り返し行われるであろう結合テストの自動化である。

ちょっと調べると、今ではCucumber-jvmなるものを利用してBDDしつつブラウザテスト自動化ができるらしいことがわかった。 だがしかし、そこにはMavenという障壁が立ちはだかるのであった。

MavenはAntに代わるJavaのビルドツールで、 pom.xmlというMavenの実行ファイルを作りこめば、 ソース・ライブラリ管理やら自動デプロイやら様々なことを自動化・フロー化することができる。 （antでいうところのbuild.xml = pom.xml）
しかしながらAntと違いかなり特殊なディレクトリ構造を構成せねばならないとか、 ちょっと取っ付きづらいxml表記や思想・概念を新たに理解しなければならないとか、 もう辟易しちゃいそうなJava特有のアレがそこには存在している。

今までAntをシコシコとイジってみてようやく覚えてきたところで、 すぐにMavenに移るというのもなかなか面倒だし、かと言ってGradleを勉強しようという気にもならない。 八方ふさがりである。というか単純に面倒くさいという気持ちが勝りすぎている。

ただし、今回の結合テスト自動化に当たっては、CucumberやSeleniumなどのツールを使うこととなり、 それを使うにはMavenが最適であることはもはや自明なのである。 もう、Mavenを避けては通れない。

「面倒だからしない。現状維持」・・・こうやって知恵遅れになっていくんだろうなぁ～。