Unit Testing ASP.NET MVC Views

I have successfully jumped onto the Test Driven Development (TDD) bandwagon now and loving it. Over the last 6 months I’ve been trying to incorporate it wherever I can; my code at work is now starting to gain a number of unit tests within a codebase that initially I thought would be difficult to do automated testing on.

Recently I’ve started a personal project using ASP.NET MVC – I haven’t had much experience of MVC, only Web Forms, and wanted to expand my knowledge on .NET web development. I’ve heard many stories how ASP.NET MVC was designed from the ground up to be very easy to test so I jumped at the chance of reading up and experimenting with it. One bonus as well is that this would be all-new code; the one thing I’ve learned about TDD is that it works brilliantly with a clean-slate, with legacy code it requires quite a bit more work and slower iterations in order to not break what you’ve already got.

For most of the MVC framework I could clearly see how you could apply unit testing to your code as it focuses a lot on plain objects. One of the things I couldn’t initially get my head around though is testing controllers and verifying that views returned were correct.

Take this example of a simple controller:

public class AccountController : Controller
{
    public ActionResult Index(int id)
    {
        Account account = new Account()
        {
            Id = id,
            Name = "My Account"
        };
        return View("Index", account);
    }
}

It is actually quite easy to write a unit test for this controller and action as, thankfully, controllers are not strongly tied to anything to do with HTTP requests or responses, so testing becomes as simple as:

[Fact]
public void IndexActionReturnsView()
{
    AccountController controller = new AccountController();
    ActionResult result = controller.Index(42);
    Assert.NotNull(result);
}

But at this point I got a little stuck. How do I know that the controller action returned the view that I wanted? Initially I was thinking only in terms of controller actions returning HTML output; how can we verify HTML text output in automated tests?

The answer is you don’t, and actually the answer is a lot simpler and cleaner; we don’t verify the overall output, we simply verify that the view has the necessary information (i.e. model data) it needs to generate the HTML output (or whatever output format is required).

This can be split up into several parts:

Check the View Name

One test can be defined to determine that the correct view was returned by checking the name of the view, such as below:

[Fact]
public void IndexActionReturnsCorrectViewName()
{
    AccountController controller = new AccountController();
    
    // Cast the result of the action to a ViewResult, this will then provide
    // view information for the test to confirm
    ViewResult result = controller.Index(42) as ViewResult;
    
    Assert.Equal("Index", result.ViewName);
}

One caveat I’ve found with this though is that in the controller you must specifically request which view you want; letting the MVC framework determine it by convention – based on the action name – doesn’t seem to work for some reason.

Check the View Model Type

The next test you can run is to ensure that the view returned was supplied with the correct model type, like so:

[Fact]
public void IndexActionReturnsCorrectViewModelType()
{
    AccountController controller = new AccountController();    
    ViewResult result = controller.Index(42) as ViewResult;
    
    // Test that the model object passed to the view was the correct 
    // type
    Assert.IsType<Account>(result.Model);
}

Check the View Model Data

Finally you can then test that the view returned was supplied with the correct model data, like so:

[Fact]
public void IndexActionReturnsCorrectViewModelData()
{
    AccountController controller = new AccountController();
    ViewResult result = controller.Index(42) as ViewResult;
    
    // Cast the model in the view result to the correct type and
    // now we can test against it
    Account model = result.Model as Account;
    
    Assert.Equal(42, model.Id);
}

Conclusion

This concept, once understood, feels incredibly clean to me. If you think about it you don’t want to test how a web page looks because that could change over time thanks to re-designs, plus parsing such information would be incredibly painful. All you need to do is verify that the view was given enough details for it to carry out it’s job; can it display a title for the page, does it have the correct list of customer orders to render, etc. It has actually made me re-think some of my code designs to better match this concept.

I can see why developers love ASP.NET MVC compared to Web Forms now!