I’m trying to get my head around how one would unit test an ASP.NET MVC project that accesses data through a repository of some sort.
During the unit tests I’d obviously want to create a mock repository but how do I pass this mock repository to the Controller instance being tested? Also how would the actual repository, that’s really connected to a database, find its way to the controller?
Do I simply do this through the constructors as I’ve shown below? I think this is how I should set up my controllers, but I’d like some confirmation that this is correct:
public class SampleController : Controller
{
private IRepository _repo;
//Default constructor uses a real repository
// new ConcreteRepo() could also be replaced by some static
// GetRepository() method somewhere so it would be easy to modify
//which concrete IRepository is being used
public SampleController():this(new ConcreteRepo())
{
}
//Unit tests pass in mock repository here
public SampleController(IRepository repo)
{
_repo = repo;
}
}
As everyone has already said, you’ll want to use an IoC* or DI** container. But what they haven’t said is why this is the case.
The idea is that a DI container will let you bypass ASP.NET MVC’s default controller-construction strategy of requiring a parameterless constructor. Thus, you can have your controllers explicitly state their dependencies (as interfaces preferably). How those interfaces map to concrete instances is then the business of the DI container, and is something you will configure in either Global.asax.cs (live) or your test fixture setup (for unit testing).
This means your controller doesn’t need to know anything about concrete implementations of its dependencies, and thus we follow the Dependency Inversion Principle: “High-level modules should not depend on low-level modules. Both should depend on abstractions.”
For example, if you were to use AutoFac, you would do this:
* IoC = inversion of control
** DI = dependency inversion
(the two terms are often used interchangeably, which is not really correct IMO)