Why Unit Test Controllers?
Controllers coordinate between models and views, and unit testing them in isolation — without a real database, real HTTP context, or a running web server — lets you verify routing decisions, validation logic, and returned ActionResult types quickly and deterministically. Dependency injection is essential here: a controller that takes an IProductRepository through its constructor can be tested against a mocked repository instead of a live database.
Cricket analogy: A batting coach analyzes a player's cover drive in a controlled net session against a bowling machine set to a fixed line and length, isolating the technique from match pressure, similar to unit testing a controller action against a mocked repository instead of a real database.
Setting Up a Test Project
A typical setup adds a class library test project referencing xUnit (or NUnit/MSTest), the Moq mocking library, and the main MVC project, along with System.Web.Mvc for the ActionResult types. Because controllers may touch HttpContextBase, Session, or Request, Moq is used to create fake implementations of those abstractions so tests never require a real IIS-hosted request.
Cricket analogy: A franchise sets up a dedicated indoor training facility with a bowling machine and video analysis rig separate from the match-day stadium, similar to setting up a dedicated xUnit test project referencing Moq separate from the main MVC web project.
public class ProductsControllerTests
{
[Fact]
public void Index_ReturnsViewWithProductList()
{
// Arrange
var mockRepo = new Mock<IProductRepository>();
mockRepo.Setup(r => r.GetAll()).Returns(new List<Product>
{
new Product { Id = 1, Name = "Widget" }
});
var controller = new ProductsController(mockRepo.Object);
// Act
var result = controller.Index() as ViewResult;
// Assert
Assert.NotNull(result);
var model = Assert.IsAssignableFrom<IEnumerable<Product>>(result.Model);
Assert.Single(model);
}
}Asserting on ActionResult Types
Because controller actions typically return the IActionResult or ActionResult base type, a robust test casts the actual returned object to its concrete type — ViewResult, RedirectToRouteResult, JsonResult, or HttpNotFoundResult — and asserts on specific properties like ViewResult.ViewName or RedirectToRouteResult.RouteValues["action"] rather than merely checking the result is not null.
Cricket analogy: A match referee checks the specific dismissal type recorded on the scorecard — caught, bowled, or LBW — rather than just noting the batsman is out, similar to asserting the concrete result type is a ViewResult versus a RedirectToRouteResult rather than just checking it's not null.
Avoid instantiating a real HttpContext or Session in unit tests. Doing so couples the test to IIS internals and makes it fragile and slow; use Moq to create a fake HttpContextBase, or better, keep controllers thin and push logic that touches HTTP concerns into testable services.
Testing Model Validation and TempData
To test how a controller reacts to invalid input, call controller.ModelState.AddModelError("Name", "Required") before invoking the action, then assert it returns the same ViewResult with the invalid model rather than redirecting. Similarly, controllers that read or write TempData (for example, a post-redirect-get success message) need a TempDataDictionary injected via controller.TempData = new TempDataDictionary() so the test doesn't depend on a real session-backed TempData provider.
Cricket analogy: An umpire simulates a specific no-ball scenario during training by deliberately overstepping to test how the third umpire's review process handles it, similar to a test calling ModelState.AddModelError to simulate an invalid model and verifying the controller returns the same view with errors.
Keep controller actions thin — validate, delegate to a service or repository, and return a result. The thinner the action, the less setup a unit test needs and the fewer branches there are to cover, which keeps the test suite fast and maintainable.
- Unit tests isolate a controller action from the real database, HTTP pipeline, and IIS by using dependency injection and mocks.
- xUnit, NUnit, or MSTest paired with Moq is the standard toolchain for classic ASP.NET MVC controller testing.
- Assert on the concrete ActionResult type (ViewResult, RedirectToRouteResult) and its specific properties, not just non-null.
- Avoid depending on a real HttpContextBase or Session; mock them or push HTTP-dependent logic into services.
- ModelState.AddModelError() simulates invalid input to test a controller's validation branch.
- TempDataDictionary must be manually injected in tests for controllers that read/write TempData.
- Thin controllers with logic pushed into services are easier and faster to unit test.
Practice what you learned
1. Why do controller unit tests typically use a mocking library like Moq?
2. What is the recommended way to assert on a controller action's result?
3. How do you simulate invalid form input in a controller unit test?
4. Why might a controller test need to manually assign controller.TempData?
5. What is a key benefit of keeping controller actions thin?
Was this page helpful?
You May Also Like
Areas in MVC
Understand how ASP.NET MVC Areas partition large applications into independently organized functional modules with their own controllers, views, and routes.
ASP.NET MVC Interview Questions
A focused review of the most commonly asked ASP.NET MVC interview topics — architecture, routing, filters, model binding, and state management — with concrete explanations.
Deploying MVC Applications
A practical guide to shipping ASP.NET MVC applications to production using Web Deploy, Azure App Service, web.config transforms, and IIS application pool configuration.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics