DbUnitでテーブルをエクセル出力する
以前のエントリで、DbUnitを使ってフィクスチャによるデータベース事前条件の定義を含むユニットテストを行う方法を示した。
事後条件については、ターゲットとなるメソッドの実行が完了した後にSimpleJdbcTemplateなどでデータベースに対しクエリを行うことでチェックすることが出来る。理想としてはそのようにしてプログラムコードだけで事後条件を自動的に検査出来るほうが良い。よく練られた多角的なテストケースが存在することにより、プログラムは修正作業によるエンバグの発生から逃れやすくなるだろう。
しかし、テストケースに山のような数のselect文やループ構文を記述している時間が惜しい時があるのも事実だ。人間が表の状態を視覚的に確認することで、(ミスの検出確率は下がるものの)事後条件のチェックにかかる時間が節約出来ることも多々ある。
ところが、基本的にフィクスチャを用いるユニットテストは各テストメソッドの実行が1つのトランザクションとなっており、成功にせよ失敗にせよテストの完了時にトランザクションはロールバックされてしまいデータベース上のテーブルは空に(正確にはテスト実行前の状態に)戻ってしまうため、テストの実行後に GUIのフロントエンドなどを用いてデータベースの内容を確認しようとしても無駄である。
DbUnitには、テーブルの内容をファイルにダンプする機能があるので、それをテスト中の任意の時点で呼び出すことでこの問題を解決出来る。下記の例では、addCommentToArticle()メソッドの実行後に users, articles, commentsという3つのテーブルをエクセルファイルに出力している。エクセルファイル上では、1つのテーブルが1つのシートに割り当てられる。
繰り返しになるが、ダンプされたエクセルデータを目視で確認し事後条件の検査をするという方法はユニットテストのあり方として理想的ではない。いうまでもなく、事後条件の検査はテストケースの中に assert文を使って記述されるべきだ。それをわかった上でどこを妥協するかは時間的制約との兼ね合いだろう。
事後条件の検査以外にもテーブルのダンプは有益な場合がある。たとえばロジックの実装者はデバッグのためにそれがあると便利なはずだ。事後条件の検査を自動で行う行わないに関わらず、テーブルのダンプを常に生成するようにしておいた方が実装者に優しいといえる。ただ、テストの最後でダンプを行うようにテストメソッドをコーディングした場合、途中のassertに引っかかるとダンプが行われないためデバッグ時には不便かもしれない。ダンプのタイミングは状況に応じて選ぶと良いだろう。
事後条件については、ターゲットとなるメソッドの実行が完了した後にSimpleJdbcTemplateなどでデータベースに対しクエリを行うことでチェックすることが出来る。理想としてはそのようにしてプログラムコードだけで事後条件を自動的に検査出来るほうが良い。よく練られた多角的なテストケースが存在することにより、プログラムは修正作業によるエンバグの発生から逃れやすくなるだろう。
しかし、テストケースに山のような数のselect文やループ構文を記述している時間が惜しい時があるのも事実だ。人間が表の状態を視覚的に確認することで、(ミスの検出確率は下がるものの)事後条件のチェックにかかる時間が節約出来ることも多々ある。
ところが、基本的にフィクスチャを用いるユニットテストは各テストメソッドの実行が1つのトランザクションとなっており、成功にせよ失敗にせよテストの完了時にトランザクションはロールバックされてしまいデータベース上のテーブルは空に(正確にはテスト実行前の状態に)戻ってしまうため、テストの実行後に GUIのフロントエンドなどを用いてデータベースの内容を確認しようとしても無駄である。
DbUnitには、テーブルの内容をファイルにダンプする機能があるので、それをテスト中の任意の時点で呼び出すことでこの問題を解決出来る。下記の例では、addCommentToArticle()メソッドの実行後に users, articles, commentsという3つのテーブルをエクセルファイルに出力している。エクセルファイル上では、1つのテーブルが1つのシートに割り当てられる。
public void testAddCommentToArticle()
{
target.addCommentToArticle(1, 2, "コメント");
// addCommentToArticle()実行後のデータベース内容をエクセルファイルにダンプ
IDatabaseConnection con = this.getConnection();
IDataSet dataset = con.createDataSet(
new String[]{"users","articles","comments"});
OutputStream os = new FileOutputStream("addCommentToArticle.xls");
XlsDataSet.write(dataset, os);
os.close();
con.close();
}
繰り返しになるが、ダンプされたエクセルデータを目視で確認し事後条件の検査をするという方法はユニットテストのあり方として理想的ではない。いうまでもなく、事後条件の検査はテストケースの中に assert文を使って記述されるべきだ。それをわかった上でどこを妥協するかは時間的制約との兼ね合いだろう。
事後条件の検査以外にもテーブルのダンプは有益な場合がある。たとえばロジックの実装者はデバッグのためにそれがあると便利なはずだ。事後条件の検査を自動で行う行わないに関わらず、テーブルのダンプを常に生成するようにしておいた方が実装者に優しいといえる。ただ、テストの最後でダンプを行うようにテストメソッドをコーディングした場合、途中のassertに引っかかるとダンプが行われないためデバッグ時には不便かもしれない。ダンプのタイミングは状況に応じて選ぶと良いだろう。

0 件のコメント:
コメントを投稿
<< ホーム