Is there any reason to use Mock objects when unit testing an Entity Framework DAL?

Question

From what I understand, Mocking is used to remove dependency of another service so that you can properly test the execution of business logic without having to worry about those other services working or not.

However, if what you are testing IS that particular service (i.e. Entity Framework), Implementation-style unit tests against a preset test database are really the only tests that will tell you anything useful.

Am I missing anything? Does mocking have any place in my testing of an Entity Framework DAL?

Answer 1

You are correct in your assertion about mocking:

Mocking is used to remove dependency of another service so that you can properly test the execution of business logic without having to worry about those other services working or not.

In my words: the idea behind unit testing is to test a single code path through a single method. When that method hands execution over to another object there is a dependency. When control passes to an unmocked dependency you are no longer unit testing, but are instead integration testing.

Data access layer testing is typically an integration test. As you speculate you can utilize a predictable data set to ensure your DAL is returning results as expected. I would not expect a DAL to have any dependencies which would require mocking. Your testing that the values returned by your DAL match what you would expect given your dataset.

All of the above said it is not your responsibility to test the Entity Framework. If you find yourself testing the way EF works and are not creating tests about your specific DAL implementation then you are writing the wrong tests. Put another way: you test your code, let someone else test theirs.

Finally, three years ago I asked a similar question which elicited answers which greatly improved my understanding of testing. While not identical to your question I'd recommend reading through the responses.

Answer 2

In my opinion, mocking objects has nothing to do with the layer you are about to test. You have a component that you want to test and it has dependencies (that you can mock). So go ahead and mock.

Answer 3

One can assume EF works. You would test your code that interacts with EF. In this case, you fake EF in order to test your interacting code.

You basically shouldn't be testing EF. Leave that to Microsoft.

Answer 4

One thing you might consider is that EF can work with a local file and not your actual repository and you can switch between the two with connection strings. This example would create the .sdf file in an AppData folder or in the bin folder if it's a console application.

<connectionStrings>
<add name="SecurityContext" 
     connectionString="Data Source=|DataDirectory|YourDBContext.sdf"
     providerName="System.Data.SqlServerCe.4.0" />

I like this when I'm starting a project or testing. You can load the DB with data and such and presto: EF has a mocked DB for you to run tests against without touching production data.