java - JavaでDAOに単体テストを適用する方法

Question

データ アクセス層に単体テストを適用する方法がわかりません。データ アクセス層をテストする必要があるかどうかは、常に疑問に思っています。私の会社では、データアクセスオブジェクトを実行して単体テストデータとテストデータアクセスレイヤーを保存し、安定したデータベースから取得したデータをチェックするための安定したデータベースがあります。

単体テストに合格するために、安定したデータベースのデータは変更できなくなります。これにはもっと良い解決策があると思います。私が間違っていなければ、モック オブジェクトは SQL ステートメントとResultSetマッピングのテストを実行できません。

DAO を単体テストする最良の方法は何ですか? TDDでこれを行うより良い方法はありますか?

Answer 1

まず、ほとんどの定義では、「単体」テストはデータベースのような外部システムに依存しません。「機能」または「統合」テストと呼ばれるものを作成したいとします。実際には、これらのタイプのテストは、Junit などを使用して単体テストと同じ方法で実装されますが、それらを単体テストから分離する必要があります。単体テストは非常に高速に実行され、データベースがダウンしたりデータが変更されたりしても壊れません。

次に、ほとんどのビジネス ロジックを DAO から除外し、代わりにサービス POJO レイヤーに配置して、データベースを使用せずにビジネス ロジックをテストできるようにします。

次に、DAO のテストをセットアップする理想的な方法は、空のデータベースから開始し、(多くの場合 DAO 自体を使用して) テスト データをロードし、既知の書き込み可能なテスト データセットに対して DAO テストを実行することです。幸運にも読み取り専用データベースを使用できる場合は、stable database概要を説明したアプローチが機能しますが、ほとんどのシステムはデータベースに対して読み取り/書き込みを行います。

最後に、DAO をテストすることは重要です。多くの場合、データベース クエリはシステムの最も壊れやすい部分の一部であり、本番環境にデプロイされるまで待ちたくありません。

Answer 2

いくつかのコメント/提案:

1. DAO テストは、実行されたクエリと取得されたデータが期待どおりかどうかを確認することを目的としています。DAO でテストするビジネス ロジックはほとんどないはずです。
2. 主な目的はデータベースの相互作用をテストすることであるため、モックを作成しても、特にエッジケースでは確実に実行できません。
3. これに照らして、あなたが現在持っているアプローチは十分に公平です。よくないと感じる理由がわかりません。ちょっとした工夫が役に立ちます。
4. 外部データベースの使用に慣れていない場合は、Javaに組み込まれているjavaDBを使用できます。このテストを実行する前に、まずテスト データを作成するためのオーバーヘッドが発生することに注意してください。