So far in the “Using SpecsFor.Mvc" series, I’ve shown you how to navigate using the strongly-typed API and how to fill out and submit forms. In part three of my series, I’ll show you how to create automated acceptance tests for your ASP.NET MVC application that verify expected data is displayed on a page.

Check out part one if you want to know more about what this configuration is doing.

The Many Ways to Display Data in ASP.NET MVC

We covered in part two that there are many ways to build forms with ASP.NET MVC. It’s also true that there are many ways to build display views. You can emit values from ViewData:

<h2>About</h2>
<p>
Today is @Html.ViewData["DayOfWeek"]
</p>

Or you can write values directly from a strongly-typed view model:

<h2>About</h2>
<p>
Today is @Model.DayOfWeek
</p>

You can also use strongly-typed helpers:

<h2>About</h2>
<p>
Today is @Html.DisplayFor(m => m.DayOfWeek)
</p>

The later approach is the preferred one, and it has several benefits. First, unlike rendering values from ViewData or ViewBag, the strongly-typed helpers give you compile-time safety. Second, the helpers are built on ASP.NET MVC’s templating system, giving you additional hooks to change how things are rendered across your application. We’ll be leveraging these templates to create testable views.

Creating Testable Views

If you aren’t familiar with ASP.NET MVC’s display and editor templates, I strongly recommend you check out Brad Wilson’s posts on the subject. We’ll be leveraging display templates here, and I’m going to assume you understand the basics.

The built-in templates included with ASP.NET MVC are actually implemented as static methods in C# and cannot be customized incrementally. Here’s the string template, buried within the bowels of the System.Web.Mvc.Html namespace:

Notice that there’s nothing about the output that makes it obvious that part of the result was pulled from the view model. This is quite different from the editor templates. They output identifiers based on the model:

In order for SpecsFor.Mvc to locate the output of our display view models, we need to tag the output in such a way that it can be identified. That’s not as easy as it should be though. Remember what I said about the display templates: they’re baked in to the System.Web.Mvc assembly. Since the built-in templates aren’t extensible, it’s unfortunately necessary to replace them completely with templates that can be customized and extended. I’ve created a NuGet package, MvcDisplayTemplates, that contains editable Razor versions of the built-in templates with only minor enhancements. The main enhancement that’s relevant here is the addition of a shared layout that wraps the output of each template with a span. Through its ID attribute, which is populated using the same logic that builds IDs for the built-in editor templates, the span element makes it very easy to determine where properties from our view model were rendered in the view:

Testing Display Views with SpecsFor.Mvc

Leveraging the test-friendly templates is easy: just render the output using HtmlHelper’s DisplayFor extension method as shown in the example above. Testing the view’s output with SpecsFor.Mvc is then very similar to interacting with and submitting forms. Navigate to the controller action, use the FindDisplayFor method to retrieve a FluentDisplay, then use the DisplayFor method to locate the elements for the various properties on your view model:

As long as the output is wrapped in a span with an ID generated off of the model, SpecsFor.Mvc should be able to locate it. The convention for naming is hardcoded in the current build of SpecsFor.Mvc and matches the approach System.Web.Mvc uses, but I plan to make that a customizable convention in the 2.0 release.

What’s Next?

Assuming you are generating views with the correct conventions (which is easy thanks to the MvcDisplayTemplates package on NuGet), SpecsFor.Mvc makes it very easy to test the output of your views. Now you know how to submit data to your app as well as how to read it back out. In the next post, I’ll show you how SpecsFor.Mvc helps you deal with authentication without adding overhead to your specs. In future posts, I’ll show you how you can load seed data into your application as well as how you can use SpecsFor.Mvc to test JavaScript-heavy applications. Stay tuned!

About Matt Honeycutt...

Matt Honeycutt is a software architect specializing in ASP.NET web applications, particularly ASP.NET MVC. He has over a decade of experience in building (and testing!) web applications.
He’s an avid practitioner of Test-Driven Development, creating both the SpecsFor and SpecsFor.Mvc frameworks.

He's also an author for Pluralsight,
where he publishes courses on everything from web applications to testing!