Should you Unit Test Business Logic methods that consists primarily of a query?

Question

I have a business logic layer with a broad spectrum of classes and their corresponding methods. Creating a Unit Test for a method is generally a given but, in some cases, the method really just returns a set of matching records from the database. It seems kind of silly to write a Unit Test by, say, storing five matching records and then calling the BLL method and see if it returns all five records.

What is best practice here? What do you actually do - as opposed to what you'd like to say you would ideally do?

Answer 1

I use DBUnit to fill in the database with a number of records, more than should be returned by the query. Then, call the method, and make sure that only the right records are returned. This ensures that your query logic works, and helps to catch regression issues in the future if you refactor the database.

Answer 2

I believe the real question here is, why do you have methods in your Business Logic Layer that don't seem to contain any real business logic?

In this case, it seems like the method in question is just a Repository style method to retrieve records matching some criteria from the database.

In either situation, I would still Unit Test the method. There are several reasons:

1. Since the method is in the Business Logic Layer (in your case), it's possible that the method could end up becoming more involved. Adding the Unit Test now will ensure that even in the future, no matter the logic, the method is still getting tested for unexpected behavior.

2. If there is any logic at all (like determining which records match the business criteria), you still have to test that logic.

3. If you end up moving the method to the Data Layer, you should be testing your query against some mock data repository to make sure your queries work. That way, if your queries become more complex in the future...you're covered.