When it comes to mocking the LINQ DataContext, it’s not an easy task to do, because DataContext (base class) doesn’t implement any interface, so you have to create a wrapper around the DataContext. I decided to follow the Unit Of Work pattern and created also a Generic Repository to access the model classes from the DataContext. I tried to dig around on the internet for articles to direct me in the right direction. All articles on the internet were old and outdated. That is the main reason I decided writing this article describing the method. I have also used this method with Entity Framework. It worked really well, so I highly recommend this method for both LINQ and Entity Framework. Later I will cover the same method with Entity Framework.  

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.   Student example In this example I will use a model class named “Student”. Because we are working with LINQ our model classes will be auto-generated, but figurately speaking our Student model would look something like this:

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 DataContext, which is our LINQ 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 LINQ UnitOfWork and our mocked UnitOfWork will implement.

Here is the IUnitOfWork interface:

Next we create a class that implements our interface. Again, this is the class that works with LINQ DataContext, 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:

Mocking

Because LINQ has no interface for DataContext we need to 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 DataContext 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. Next time I will use the same method/pattern for Entity Framework, but it’s slight different because you have to create IDataContext that our DataContext and MockDataContext implement. More on that later.