How unit test queries on data?

Question

How to unittest a fairly simple application?

By "fairly simple application" understand:

An application that queries a database (that can be complex) through an ORM and displays the result without any further processing. That's, the Linq query returns a simple IEnumerable that will be displayed on the screen.

The kind of tests I'm writing so far tends to be slow and I delay more and more their execution. If I keep this process, these tests will only be executed when I commit the code and thus I'll loose all the benefits of unit test: highlight bugs or errors within a minute.

I tried to make an object graph in memory but as the application grows this graph become very complex and it's taking more and more time to be maintained. And when I plug the ORM instead of object graph, I see bugs my unit tests didn't foresee...

In my case, I need a generic solution as the ORM should be either Entity Framework or nHibernate.

EDIT:

I rephrase my question as it is maybe a bit unclear: test this kind of application means test the queries. What is the best manner to test Linq queries?

Answer 1

Johnny Graber's answer is similar, but I'll add mine anyway for sake of several opinions.

To answer specifically on your issue with testing Linq queries (and still, this is my opinion, like in the comment above): you don't test them.

As nice and simple Linq is, it is basically as bad having a lot of Linq queries in a project as it is to have hardcoded SQL statements.

Hence, the Linq queries should be part of a data abstraction layer and that layer is what you test. That layer provides basic access methods, mostly CRUD operations. These operations might be implemented using Linq against whatever (SQL, SQLite.Net, XML, you name it).

You should then have another implementation of your DAL which returns/generates mock data. No need to use Linq here.

You can then test, if you're application works against the implementation that contains mock data, which is fast, as it's memory based. You worry about the outcome of these methods.

You can from time to time switch over to the productive version that's based on Linq and run the slower tests. Linq itself works. Microsoft did a pretty good job. You need to worry about your access methods returning proper data.

Answer 2

The simple answer to your question is not to unit test data queries. As you found out the value of unit testing this part of the application is very limited and most of the bugs don't show up. The ORM is a good place for integration testing.

To enable this your data access code must be put in one place. Depending on your application this may be a data access layer, a Repository or any other structure that enables you to split your business logic from your data access. In the business logic part you use unit tests and mock or replace the data access with an in memory solution. The data access part you test with integration tests. But here you only have to test if you can insert, update, select or delete data and if your queries work. That should be doable with way less tests than if you would try to do this all within your unit tests.

Entity Framework and nHibernate both have tutorials on how you can use those frameworks for this kind of testing.