Unit Testing MVC Controllers

Analogy categoryAnalogies

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.

csharp

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.