これは実際には、効率的にテストする方法についてのより深い問題であり、多くの異なる意見を見つけることができます。
単体テストでデータベースを避ける理由は、単に速度です。データベース操作が遅い。1 回のテストでは遅くないように見えるかもしれませんが、継続的インテグレーションが (当然のことながら) 進行している場合、または簡単な変更を行って何が起こるかを確認したいだけの場合は、これらの遅延が加算されます。したがって、真の単体テストコードよりもモックを好みます。
次に、独自の統合テストは、実際のデータベースではなくメモリ内データベースにヒットする必要があります。同じ理由で、速度です。これらは模擬テストよりも遅くなりますが、実際のデータベースにアクセスするよりは高速です。開発中は、ビルド、テスト、デプロイのサイクルをできるだけ速くする必要があります。これらを単体テストと呼ぶ人もいることに注意してください。私はしませんが、それは単なるセマンティクスだと思います。
最初の 2 種類のテストは、開発者による開発者向けのものです。
次に、テスターは実際のデータベースにアクセスします。このデータベースには、テスターと対象分野の専門家によって定義されたテスト データが入力されます。これを高速化するための巧妙な方法もたくさんありますが、これは、コードと本番環境のようなデータベースとの統合をテストする場所になります。すべてのインメモリ データベース テストに合格し、ここで問題が発生した場合は、根本的な問題ではなく、データベース構成、ベンダー固有の SQL などに関係があることがわかります。また、パフォーマンスがどのようなものかを初めて味わうこともできます。
ここで述べたことはすべて、議論の問題であることに注意してください。しかし、うまくいけば、特定のことをいつ、なぜ行うべきかについて、何を考慮すべきかが明確になります。