幅広いクラスとそれに対応するメソッドを備えたビジネスロジックレイヤーがあります。メソッドの単体テストの作成は一般的に与えられていますが、場合によっては、メソッドは実際にはデータベースから一致するレコードのセットを返すだけです。たとえば、一致する5つのレコードを格納し、BLLメソッドを呼び出して、5つのレコードすべてが返されるかどうかを確認することで、単体テストを作成するのはちょっとばかげているようです。
ここでのベストプラクティスは何ですか？理想的には何をしたいのかとは対照的に、あなたは実際に何をしますか？
ここでの本当の質問は、ビジネスロジックレイヤーに実際のビジネスロジックが含まれていないように見えるメソッドがあるのはなぜかということだと思います。
この場合、問題のメソッドは、データベースからいくつかの基準に一致するレコードを取得するための単なるリポジトリスタイルのメソッドのようです。
どちらの状況でも、メソッドの単体テストを行います。いくつかの理由があります：
メソッドはビジネスロジックレイヤー（あなたの場合）にあるため、メソッドがより複雑になる可能性があります。ここで単体テストを追加すると、将来的にも、ロジックに関係なく、メソッドが予期しない動作についてテストされていることが保証されます。
ロジックがある場合（どのレコードがビジネス基準に一致するかを判断するなど）、そのロジックをテストする必要があります。
メソッドをデータレイヤーに移動することになった場合は、クエリが機能することを確認するために、いくつかのモックデータリポジトリに対してクエリをテストする必要があります。そうすれば、将来クエリがより複雑になった場合...あなたはカバーされます。
DBUnitを使用して、クエリで返されるはずの数を超える数のレコードをデータベースに入力します。次に、メソッドを呼び出し、正しいレコードのみが返されることを確認します。これにより、クエリロジックが確実に機能し、データベースをリファクタリングする場合に将来のリグレッションの問題を検出するのに役立ちます。