 |
||||||||||
|
DBUnitのメリット DBUnitを利用するメリットは冒頭でも述べたように、JUnitのメリットをそのまま受け継いでいる点でしょう。 まず、テスト仕様書のような文章ではなく、DBUnitのテストクラス（テストコード）として記述するため、テスト結果の曖昧性がなくなります。 次に、テストコードを作成しているため、積極的なリファクタリングが行えます。プログラムすべてに対応するテストクラスを作成すれば、リファクタリングを行った時に他の機能に影響があるか簡単に確認できます（リファクタリングとは、プログラムの振舞いを変えることなくソースコードを修正すること）。 また、DBUnitのテストコードを作成することにより、単体テスト仕様書が必要なくなります。 さらに、先ほど述べたJUnitにはないDBUnitの拡張機能である「データベースへテストデータの流し込みの機能」「テストの事後状態と期待値を比較する機能」「データベースからテストデータの削除を行う機能」が利用できます。 実際に、DBUnitを使用すると事前データや期待値データは、外部ファイルで設定できるようになります。これは大変有益なメリットです。 障害や機能追加で次々とテストを行う場合、労力をかけてテストデータを用意し、テスト実施後に期待値を目で確認するのは大変な作業ですが、DBUnitを用いるとこの面倒に思えてしまう作業が、むしろ楽しいとさえ思えるようになります。実際に、筆者は楽しくテスト作業を行っています。JUnit同様にテスト実行後、テストOKの緑のバーが表示されると思わず「よっしゃー！」という気分になります。 プロジェクトに仕様変更や機能追加はつき物です。テストを繰り返す労力が軽減されるのがDBUnitの最大のメリットと言えるでしょう。良いことづくめのような感じに見えますが、デメリットもあります。  DBUnitのデメリット もっとも大きなデメリットは、DBUnitはJUnitと同様にテストコードを作成するのにたくさんの工数を必要とすることでしょう。また、DBUnitを使えるようになるためには、多少の知識の習得とセットアップの時間も必要です。 さらに、プログラムに改修が入った場合、作成したテストコードもあわせて改修する必要があります。 このようにDBUnitを利用する場合は、DBUnitを利用しない場合と比較して工数が増えてしまうという点は、筆者も否定しません。 しかしながら、DBUnitを利用するとテスト後に発生する障害対応や機能追加、また仕様変更で再テストを繰り返し行う場合の工数が軽減できるため、さほどデメリットにはならないでしょう。 さて、今回はDBUnitの特徴について話を進めてきました。次回は実際にDBUnitをインストールしていきます。また、テストデータを作成する事前準備について焦点を当て解説していきます。 |
||||||||||
|
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
