JUnitじゃだめなのか？

一般的に広まっているJUnitですべての単体テストを行えれば、実は何も問題がありません。しかし、残念ながら、「データベースへ、テストデータの流し込む機能」や「テストの事後状態と期待値を比較する機能」「データベースからテストデータの削除を行う機能」がJUnitには備わっていません。

「データベースへ、テストデータの流し込む機能」とは、元データを退避し、事前準備として用意したテストデータファイルから、データベースへテストデータを流し込む機能です。

「テストの事後状態と期待値を比較する機能」とは、データベースアクセス後の戻り値、およびデータベースの状態が期待通りか否かを確認する機能です。

「データベースからテストデータの削除を行う機能」とは、データベースに流し込んだテストデータを削除し、退避した元データを復元する機能です。

JUnitではこれらの機能が備わっていないため、テストを行う場合に「データベースに絡む部分は自前で作り込む必要がある」のです。

また、JUnitでテストを行い実行結果が期待値と異なった場合、テスト対象のプログラムに誤りがあるのか、データベース絡みで作り込んだ箇所に誤りがあるのかの切り分けができなくなってしまいます。切り分けができれば、「実行結果が期待値と違った！ → テストしたプログラムが悪い！」と判断できますが、JUnit単体ではそのような切り分けが難しいのです。

JUnit＋モックオブジェクトでのアプローチ

JUnitを使ったテストのアプローチとしては、プログラムの中でデータベースにアクセスする箇所にモックオブジェクトを利用し、データベースから切り離してテストする方法もあります。

モックオブジェクトとは、実際のオブジェクトとインターフェースを同一にしたテスト用の疑似オブジェクトです。疑似というのは、実際のクラスのようにビジネスロジックがなく空実装しているという意味です。

つまり、データベースにアクセスする箇所にこのモックオブジェクトを使うことで、実際にデータベースにアクセスすることなくテストが行えます。その他の個所は、データベースと分離するため、JUnitでテストができるという仕組みです。

しかし、この方法は皆さんもお察しの通り、「データベースにアクセスする箇所のテストが取り残されてしまう」という欠点があります。

例えば、データベースに正しくコネクションが張れるか、SQL文が正しいか（文法的に間違っていないか）、などデータベースにアクセスしてみないと分からない点が多数残ることになるのです。

エラーを発見するタイミングは、データベースを繋げる結合テストに移ってからになるため、結合テストでバグや問題が発生する可能性があります。そのため、あまりお勧めはできません。

そこで、DBUnitの登場です。 次のページ