About the book

This is an example chapter of the book ASP.NET MVC 3 in Action, Third Edition. It has been published with the exclusive permission of Manning.

Written by: Jeffrey Palermo, Jimmy Bogard, Eric Hexter, Matthew Hinze, and Jeremy Skinner
Pages: 450
Publisher: Manning
ISBN: 9781617290411

Testing Inbound Routes

When compared with the rest of the ASP.NET MVC Framework, testing routes isn't easy or intuitive because of the number of abstract classes that need to be mocked. Doing this by hand requires a lot of setup code, as seen in listing 1.

Listing 1: Testing routes the hard way

If all our route tests looked like listing 1, nobody would even bother testing routes. Those specific stubs on HttpContextBase and HttpRequestBase weren't lucky guesses either; it took a peek inside Red Gate's Reflector tool to find out what to mock. This isn't how a testable framework should behave!

Luckily, the MvcContrib project has a nice fluent route-testing API that we can use to make testing these routes easier. To begin, we'll need to ensure the MvcContrib.TestHelper assembly is installed by issuing the command Install-Package MvcContrib.Mvc3.TestHelper-ci in the NuGet Package Manager Console, as shown in figure 1.

Figure 1: Installing the MvcContrib Test Helper via NuGet

Listing 1 is the same test but using MvcContrib's route testing extensions.

Listing 2: Cleaner route testing with MvcContrib XE "MvcContrib" ‘s TestHelper project

We begin by registering our application's routes in the test fixture's setup by using the static RegisterRoutes method from the Global.asax. The actual test itself is done with the magic and power of extension methods and lambda expressions. Inside MvcContrib's test helper there's an extension method on the string class that builds up a RouteData instance based on the parameters in the URL. The RouteData class has an extension method to assert that the route values match a controller and action.

You can see from listing 1 that the name of the controller is inferred from the generic type argument in the call to the ShouldMapTo<TController method. The action is then specified with a lambda expression. The expression is parsed to pull out the method call (the action) and any arguments passed to it. The arguments are matched with the route values. More information about these route testing extensions is available on the MvcContrib site at http://mvccontrib.org.

Now, it's time to apply this to our example store's routing rules and make sure that we've covered the desired cases. We do that in listing 2.

Listing 3: Testing our example routesxe "Code Camp Server:testing routes"

Each of these simple test cases uses the NUnit testing framework. They also use the ShouldMapTo<T> extension method found in MvcContrib.TestHelper.

After running this example, we can see that all our routes are working properly. Figure 2 shows the ReSharper test runner results. (The output may look slightly different depending on your testing framework and runner.)

Figure 2: The results of our route tests in the ReSharper XE "ReSharper"  test runner

Summary

Armed with these tests, we're free to modify our route rules, confident that we aren't breaking existing URLs on our site. Imagine if product links on Amazon.com were suddenly broken due to a typo in some route rule... Don't let that happen to you. It's much easier to write automated tests for your site than it is to do manual exploratory testing for each release.

About Manning Publications

Manning Publication publishes computer books for professionals--programmers, system administrators, designers, architects, managers and others. Our focus is on computing titles at professional levels. We care about the quality of our books. We work with our authors to coax out of them the best writi... This author has published 33 articles on DotNetSlackers. View other articles or the complete profile here.