Earlier I wrote an article about how to mock the LINQ DataContext. I promised to write an article about how to do the same method with Entity Framework. It’s quite similar, but the only difference is creating an IDbContext interface and using DbSet<T>.

You can get the code from GitHub

The method

The main point is to create a Unit Of Work pattern that handles the context and keeps track of our repositories. The repository is then accessable through a Generic Repository pattern that specifies the same functions for all model classes, mocked or real.

Next we create a service layer which handles all business logic. It only contains IUnitOfWork interface, so with IoC / dependency injection we can inject either real or mocked UnitOfWork. The service layer doesn’t care what kind of data it is getting. It just talks to Unit Of Work which then delivers the data. This is so we can test our logic (service layer) in isolation. When you have many services that use the same Unit Of Work instance, you don’t have to worry about DataReader conflicts, because the Unit Of Work only makes a DataContext instance in the constructor, when an instance of UnitOfWork is created. So when dealing with many services, you only have one instance of the context. Unit Of Work handles that for us.

Student example

In this example I will use a model class named Student. Our Student model would look something like this:

We start off by creating an interface for DbContext, called IDbContext, which our DataContext and MockDataContext will implement.

Here is theIDbContext interface:

Next I created an StudentDBContext class, which will inherit DbContext base class and implement IDbContext.

Here is the StudentDBContext class:

Also the mapping class for the Student.

Here is the StudentMap class:

Generic Repository

I used a Generic Repository pattern to access my model classes. This is so I have generic actions for each model class (add/delete/update/getall, etc).

Here is my IRepository interface:

Next I created the Repository class that implements the interface. This class will work with AppDataContext, which is our EF DataContext. Later on we will also create a MockRepository that will handle our mocked data, but here is my Repository class:

Unit Of Work

Next step is to create the Unit Of Work. We start off by creating an interface that both our EF UnitOfWork and our MockUnitOfWork will implement.

Here is the IUnitOfWork interface:

Next we create a class that implements our interface. Again, this is the class that works with EF AppDataContext, not our mocked one.

Here is the UnitOfWork class:

Service layer

All of our business logic will be created in a service layer, because the controllers should not contain any logic. This is so all our logic can be in one place and that the same logic can be unit tested with mocked data.

So here is my StudentService class:


Next we create a seperate implementation of our Repository and UnitOfWork classes, to work with mocked data. It’s a good practice to keep this in a seperate test project, in a namespace/folder called Mock or something like that.

Here is my MockRepository class:

Here is my MockUnitOfWork class:

Unit Test

Next we create our unit tests against our service layer. The service layer doesn’t care where it gets the data from. All it knows it talks to Unit Of Work that provides the data. This is so the logic can be unit tested in isolation. But first we need to implement our mocked AppDataContext with our fake data.

Here is the MockDataContext class:

I created an example StudentServiceTest that tests all functions in the StudentService class. For this I use VisualStudio UnitTest library (Microsoft.VisualStudio.TestTools.UnitTesting).

Here is the StudentServiceTest class:

So here we go. This is my method of creating a mocked testable service layer with mocked/real DataContext, using Unit Of Work and Generic Repository pattern.