弊社ではテストのエビデンスとして、JUnitの結果とコードのカバレッジを提出するルールにしておりますが、開発者それぞれの環境でallTestをするようなこともあります。その時に環境によっては、マシンのスペックが悪くallTestにけっこう時間が掛かってしまうこと、またその影響でマシンの負荷が高くなり、他の作業を並行してやれず仕事にならないようなことがありました（注1）。その対応としてJenkinsにブランチのallTestが流せるジョブを作って対応しました。
あと、Jenkinsのバージョンはこまめに更新した方が良いなと実感しました。バージョンアップする前はビルド、AllTest、ページビューなどが結構遅くて、周りの人からも遅いという声があがっていました。改善として、サーバのスペックをすぐに上げることは無理そうだったので、jvmのチューニングをしたりしましたがさほど効果はなく、Jenkinsのバージョンを上げてみたら劇的に早くなるということがありました（実際Jenkinsのバージョンを調べたら、1年くらい前のものを使っていた）。
Jenkinsのコミュニティはかなり活発で、日々バージョンアップしているので、長い間バージョンアップしていない方は、こまめな更新をおすすめします（自戒も含め）。
それでは、前置きはこれくらいにして、今回はDBUnitについて（1）説明～（2）使い方～（3）弊社の事例という形でDBUnitについて紹介させていただこうと思います。よろしくお願いします。
補足ですが、弊社システム部には好きなPCを買っていい制度がありまして、すべてのマシンが低スペックというわけではありませんので、入社のご意思があるかたはご心配なく。私のPCはCore i7、メモリ16GB、SSDです。
対象読者
今回の対象読者は、下記のとおりです。
- 実際の開発プロジェクトへの自動テストの導入を検討されている方
- JavaによるWebアプリケーション開発についての知識がある方
- JUnitの基本的な知識がある方
必要な環境
- JDK 7
- Eclipse 4.3
- Tomcat 7
DBUnitとは
JUnit導入にあたり、テストデータの作成方法を検討すると思いますが、弊社では今回の記事で紹介するDBUnitを採用することにしました。DBUnitとは、簡単にいうと「CSV、XML、Excelなどで記述したテストデータをデータベースに登録、削除してくれるツール」です。他にもデータをエクスポートする機能や、テストケース実施後のデータが予想した値になっていることを検証する機能も提供されています。
なぜDBUnitを採用したのかというと、DBUnitはJUnitを拡張したフレームワークなので相性が良く、簡単なAPIなので導入も容易だったからです。また、視覚的に分かりやすいExcelファイルからインポートする機能も提供されているということもあり、このフレームワークを採用しました。DBUnitを使わなくても、テスト機で利用しているテストDBのデータを利用して、テストケースを作る方法も考えられるとは思いますが、この方法では、以下のような問題が起こります。
「開発者も含めて、多くの方がデータを変更するので、テストケースで使用しているデータの状態が変わってしまい、テストケースが失敗する」
当たり前ですが、上記のようなことが起こるので、弊社ではJUnit用のスキーマ＋DBUnitという形で利用しています。
