Question

In my ASP.Net MVC application I am using IoC to facilitate unit testing. The structure of my application is a Controller -> Service Class -> Repository type of structure. In order to do unit testing, I have I have an InMemoryRepository class that inherits my IRepository, which instead of going out to a database, it uses an internal List<T> member. When I construct my unit tests, I just pass an instance of an internal repository instead of my EF repository.

My service classes retrieve objects from the repository through an AsQueryable interface that my repository classes implement, thus allowing me to use Linq in my service classes without the service class while still abstracting the data access layer out. In practice this seems to work well.

The problem that I am seeing is that every time I see Unit Testing talked about, they are using mock objects instead of the internal method that I see. On the face value it makes sense, because if my InMemoryRepository fails, not only will my InMemoryRepository unit tests fail, but that failure will cascade down into my service classes and controllers as well. More realistically I am more concerned about failures in my service classes affecting controller unit tests.

My method also requires me to do more setup for each unit test, and as things become more complicated (e.g. I implement authorization into the service classes) the setup becomes much more complicated, because I then have to make sure each unit test authorizes it with the service classes correctly so the main aspect of that unit test doesn’t fail. I can clearly see how mock objects would help out in that regard.

However, I can’t see how to solve this completely with mocks and still have valid tests. For example, one of my unit tests is that if I call _service.GetDocumentById(5), It gets the correct document from the repository. The only way this is a valid unit test (as far as I understand it) is if I have 2 or 3 documents stored, and my GetdocumentById() method correctly retrieves the one with an Id of 5.

How would I have a mocked repository with an AsQueryable call, and how would I make sure I don’t mask any issues I make with my Linq statements by hardcoding the return statements when setting up the mocked repository? Is it better to keep my service class unit test using the InMemoryRepository but change my controller unit tests to use mocked service objects?

---

Edit:
After going over my structure again I remembered a complication that is preventing mocking in controller unit tests, as I forgot my structure is a bit more complicated than I originally said.

A Repository is a data store for one type of object, so if my document service class needs document entities, it creates a IRepository<Document>.

Controllers are passed an IRepositoryFactory. The IRepositoryFactory is a class which is supposed to make it easy to create repositories without having to repositories directly into the controller, or having the controller worry about what service classes require which repositories. I have an InMemoryRepositoryFactory, which gives the service classes InMemoryRepository<Entity> instantiations, and the same idea goes for my EFRepositoryFactory.

In the controller’s constructors, private service class objects are instantiated by passing in the IRepositoryFactory object that is passed into that controller.

So for example

public class DocumentController : Controller
{
    private DocumentService _documentService;

    public DocumentController(IRepositoryFactory factory)
    {
        _documentService = new DocumentService(factory);
    }
    ...
}

I can’t see how to mock my service layer with this architecture so that my controllers are unit tested and not integration tested. I could have a bad architecture for unit testing, but I’m not sure how to better solve the issues that made me want to make a repository factory in the first place.

Answer 1

One solution to your problem is to change your controllers to demand IDocumentService instances instead of constructing the services themselves:

public class DocumentController : Controller
{
    private IDocumentService _documentService;

    // The controller doesn't construct the service itself
    public DocumentController(IDocumentService documentService)
    {
        _documentService = documentService;
    }
    ...
}

In your real application, let your IoC container inject IRepositoryFactory instances into your services. In your controller unit tests, just mock the services as needed.

(And see Misko Hevry’s article about constructors doing real work for an extended discussion of the benefits of restructuring your code like this.)