1

基礎となるメモリ内データベースを使用してテスト用のテスト データを作成したいと考えています。一般的なアプローチは、いくつかのtest_data.sqlファイルを作成し、挿入を含むテスト オブジェクトを作成することです。そして、これらのオブジェクトを Java テストで参照します。

私はGrowing Object-Oriented Software, Guided by Testsで、テストは詳細に掘り下げる必要はないことを読みました。たとえば、テストで NEW ステータスの既存のユーザーが必要な場合、ユーザーを作成してすべてのフィールドに入力する必要はありません。しかし、彼は、新しいステータスのユーザーが必要であり、他のすべてのフィールドにデフォルト値を入力する必要があることだけを伝えるべきです。

したがって、次のようなヘルパー メソッドが必要です。

User user = user(UserStatus.NEW); // inserts user in database
// ... use persistent user instance in test

しかし、私のデータベーススキーマには多くのテーブルがあり、次のコードにたどり着きました:

Domain domain = new DomainBuilder().user(UserStatus.NEW).agreement().account().account().build();

ドマンクラス:

public class Domain {
    private User user;
    private Agreement agreement;
    private Account account;
    // getters/setters
}

このコードは、ユーザー、契約 (ユーザーへの FK を使用)、2 つのアカウント (契約への FK を使用) を作成し、これらのエンティティを含む Domain オブジェクトを返します。

したがって、このコードを使用すると、基本的に特定のテストのテスト データを 1 行でセットアップできます。

このテスト データ生成アプローチには、SQL よりも次のような利点があります。

  • 一部の列/制約が追加/削除された場合、すべてのテーブル列に固執するわけではありません。テストでテストデータの生成を変更する必要はありません。

  • SQL の方がより簡潔な方法です。テスト データを 1 行でセットアップできますが、SQL アプローチではオブジェクトごとに INSERT を記述する必要があります。

  • 時間がかかりません。はい、最初にこのアプローチを使用し始めると、そのようなドメイン ビルダーの実装に時間を費やす必要がありますが、完了すると、多くの時間を節約できます。

  • 集中オブジェクト作成。データベース スキーマが変更された場合、オブジェクト作成ロジックを 1 か所だけ変更する必要があります。

  • USER_WITH_NEW_STATUS_ID のような Java 定数に固執する必要はありません。

私の質問は：

誰かがこのアプローチに来て、これに使用するライブラリ/ツール/慣習は何ですか?

更新: いくつかのテスト タイプでこのようなアプローチを使用します。

  • リポジトリのテスト (例: リポジトリがオブジェクトを正しくフィルター処理する、またはオブジェクト リストを正しい順序で返す)。

  • ビジネス ロジック + データベース統合テスト (単体テストは優れていますが、ビジネス ロジックとリポジトリ ロジックが一貫していることを 100% 確認する必要がある場合もあります)

4

1 に答える 1