Replicating LINQ to Entities Behavior in Unit Tests Using LINQ to Object

Question

In my solution, I have unit tests that are independent of the database, but rather tests with errors and integration that have external dependencies, such as the database.

When I do unit tests with mocks, LINQ to Object is used. When integration tests or a valid program are executed, LINQ to Entities is used and it is more rigorous than LINQ to Object.

Is there a way to replicate the behavior of LINQ To Object more stringent in my unit tests?

Answer 1

Once your module checks the logic with the IQueryable provided by EF, you simply cannot test it with unit tests, taunting EF. This will always result in a switch from linq-to-entity to linq-to-objects. In the case of something simplified, the right way to handle this in unit test is fake, not layout. A fake will mimic a dependency behavior. In this case, writing a fake means writing an EF provider that works with the collection in memory, just like a real provider works with a database. Writing such a provider is probably the project itself.

Because of this, as soon as your logic contains linq-to-entities queries, you should always test it with integration tests or reorganize the code so that the query itself is in a separate method (verified by integration tests), and the old logic now has a dependency on a class containing this method instead of EF itself - this leads to a repository template where IQueryalbe not displayed, but the repository provides a method for each required query that runs on an entity. I personally do not like such repositories. Here is a recent discussion about various repository implementations.

If you decide to use integration tests that modify the database in memory, then with EFv4.1 and the code, you can first change the code for connecting to SQL Compact 4, and it will work (if you do not use any special direct SQL calls or requires some special SQL types when matching). In the case of EF with an EDMX file, this will not work because the EDMX file is closely related to the exact version of the database. Having a special EDMX for unit testing only is not an option because you will be testing another code again.

Related questions are asked here to discuss problems with unit testing EF code and repositories.

Answer 2

You can use the repository template to define the IRepository interface, in your actual code, it can be implemented using the Entity Framework, and in your unit test you can use the mock framework to return objects for testing.

Answer 3

If you want your unit tests for a layer that spoke to the database to have real value and all the behavior, as in production code, you need to talk to the database. This can be considered a violation of the rule of absence of dependencies in the unit test, but there is no other way for LINQ to Entities to do its work, rather than letting it talk to the real database. It can (and probably should) be a database in memory - see, for example, how Ayende does it .