テストするときは、モックデータベースオブジェクトまたはリポジトリを使用することを私は永遠に読んだようです。他の人のDBコードをテストする理由はありませんよね？コードを実際にデータベース内のデータと混同させる必要はありませんよね？
最近、データベース（おそらくメモリ内）をセットアップし、テストを実行するためだけにテストデータをシードするテストが表示されます。
一方のアプローチはもう一方のアプローチよりも優れていますか？シードされたデータを使用したテストを実行する価値がある場合は、モックデータベース接続を気にする必要がありますか？もしそうなら、なぜですか？
データベースと対話するコードをテストする方法はたくさんあります。
リポジトリ パターンは、データ アクセス コードにファサードを作成する 1 つの方法です。テスト中にリポジトリを簡単にスタブ/モックアウトできます。これは、ビジネス ロジックの一部を分離してテストする必要があり、ダミー値がコードのさまざまなブランチのテストに役立つ場合に役立ちます。
偽のデータベース (メモリ内またはローカル ファイル) はあまり一般的ではありません。これは、実際のデータベースと偽のデータベースからデータを読み取る方法を知っている「ミドルウェア」が必要になるためです。通常は、全体にレポジトリを用意し、レポジトリをモックアウトするのが理にかなっています。このアプローチは、既存のインフラストラクチャがある一部の古いシステムでより実現可能です。たとえば、実際のデータベースを使用してから、テスト パフォーマンス上の理由から偽のデータベースに切り替えるとします。
別のオプションは、実際のデータベースを使用して、偽のデータを入力することです。この方法は時間がかかり、多くのスクリプトを作成する必要があります。ただし、このアプローチは、統合テストの一部としてかなり一般的です。以前は、テストの実行後にデータベース トランザクションを使用して変更をロールバックする、多くの「トランザクション」テストを作成していました。特定のテーブルですべての CRUD 操作をまとめて実行する 1 つの大規模なテストを作成します。
最後の方法は、SQL の結果をオブジェクトに変換するコードをテストする場合に適しています。SQL が無効である可能性があります (または間違ったストアド プロシージャ名を使用しています)。また、オブジェクトへのマッピング時に null のチェック、無効なキャストの実行などを忘れがちです。このコードは、ある時点でテストする必要があります。ORM は、このテストの多くを軽減するのに役立ちます。
私は最近かなり怠け者です。リポジトリを使用します。私のデータ層コードのほとんどは、実際の統合テスト (ダミー データで実際のデータベースにヒットする) を実行するときに変更されるため、個々のデータベース呼び出しをテストする必要はありません (トランザクション テストは不要です)。また、ほとんどの SELECT ステートメントを実行するために ORM を使用しています。業界の多くは、このより怠惰なアプローチに向かっていると思います。
両方を使用する必要があります。
ビジネス サービスは DAO に依存し、DAO をモックしてテストする必要があります。これにより、迅速で実装が容易で、保守が容易なテストが可能になります。
DAO 固有の役割は、データベース アクセス コード (クエリなど) を含めることであり、テストも行う必要があります。そのため、テスト データを使用してテスト データベースを使用し、そのクエリが返す/保存するためにサポートされているものを返す/保存することを確認する必要があります。
私は、実稼働環境で使用されるものとは異なり、インメモリ データベースを使用することはあまり好きではありません。一部のクエリ、制約などの動作はデータベースごとに異なります。テストでのみ使用されるメモリ内データベースではなく、本番データベースでコードが機能することを確認してください。