Behind the scenes, when your controller is invoking one of its action methods and is trying to find suitable values for the method's parameters, it obtains values using framework components called value providers and model binders.

Value providers represent the supply of data items available to your controller. There are built-in value providers that fetch items from Request.Form, Request.QueryString, Request.Files, and RouteData.Values. Then, model binders take all these data items and try to map them onto whatever type of parameter your method takes. The built-in default model binder can create and populate objects of any .NET type, including collections and your own custom types. You saw an example of all this working together at the end of Chapter 6, when you allowed administrators to post a form containing multiple fields and received all this data as a single Product object.

To learn how these powerful, convention-based mechanisms work, including how different context objects are prioritized, how the system works recursively to populate entire collections and object graphs, and how it can use model metadata to validate incoming values, refer to the coverage of value providers and model binding in Chapter 11.

If the framework can't find any match for a particular parameter, it will try to supply null for that parameter. This is fine for reference/nullable types (such as string), but for value types (such as int or DateTime) you'll get an exception.^[58] Here's another way to think about it:

I'm not talking about UI validation here—if your intention is to provide the end user with feedback about certain form fields being required, see the "Validation" section in Chapter 12.

In the previous chapter, you learned how you can configure the routing system to pass default values for parameters when no value is given in the request. But you wouldn't usually want to create a whole new routing entry just to configure a default value for a single action method, because there's a much quicker and simpler alternative: you can use the [DefaultValue] attribute on the action method parameter itself—for example:

public ActionResult Search(string query, [DefaultValue(1)] int page)
{
    // ...
}

Now, the framework will still use the normal system of value providers and model binders in an attempt to populate the page parameter with a value from the incoming request, but this time if no value is found, it will pass the value 1 instead of throwing an exception.

If you're using Visual Studio 2010 (even if you're targeting .NET 3.5), you can use the new C# optional parameter syntax instead, which achieves the same result while looking slightly more elegant:

public ActionResult Search(string query, int page = 1)
{
    // ...
}

When using default parameter values, here are a few points you should bear in mind:

This only works with literal values of simple types such as int, string, and enumerations, because .NET's attributes and optional parameters only allow values that are compile-time constants. You can't write [DefaultValue(new MyType(...))], nor can you refer to static fields as in string myParam = string.Empty (note that string.Empty is a read-only static value, not a compiler constant, so that at runtime there is only a single instance of it in memory). In particular, you can't specify a default value for a DateTime parameter, because C# has no syntax to represent date literals. This is not a serious problem, however, because you can always work around it by accepting null (making your parameter type nullable if necessary) and then adding code to the top of your action method that replaces any incoming null values with your desired default.

If the incoming request does contain a value for your parameter, but the value can't be converted to the parameter type (e.g., for an int parameter, any value that can't be parsed as an int), then the framework will pass your default value rather than throwing an exception. If you need to detect and handle this situation, refer to the coverage of validation in Chapter 12.

The [DefaultValue] attribute and the C# optional parameter syntaxes are usually equivalent, but not always. They rely on different underlying reflection APIs, so there is a possibility for inconsistency. In particular, if you want to set up a default value for a custom enum parameter, you will have to use [DefaultValue] because the C# optional parameter syntax won't work.^[59]

For completeness, it's worth noting that action methods aren't allowed to have out or ref parameters. It wouldn't make any sense if they did. ASP.NET MVC will simply throw an exception if it sees such a parameter.

You've seen how to render a view according ASP.NET MVC's naming and folder conventions, but you can also bypass those conventions and supply an explicit path to a specific view template—for example:

public class AdminController : Controller
{
    public ViewResult Index()
    {
        return View("~/path/to/some/view.aspx");
    }
}

Note that full paths must start with / or ~/, and must include a file name extension (usually .aspx). Unless you've registered a custom view engine, the file you reference must be an ASPX view page.

As you know, controllers and views are totally different, independent things. Unlike in traditional ASP.NET Web Forms, where the code-behind logic is deeply intertwined with the ASPX markup, the MVC Framework enforces a strict separation between application logic and presentation logic. Controllers supply data to their views, but views do not directly talk back to controllers. This separation of concerns is a key factor in MVC's tidiness, simplicity, and testability.

The mechanism for controller-to-view data transfer is ViewData. The Controller base class has a property called ViewData, of type ViewDataDictionary. You've seen ViewDataDictionary at work in many examples earlier in the book, but you might not yet have seen clearly all the different ways you can prepare ViewData and dispatch it from your controller. Let's consider your options.

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

public ViewResult ShowPersonDetails()
{
    Person someguy = new Person { Name = "Steve", Age = 108 };
    ViewData["person"] = someguy;
    ViewData["message"] = "Hello";
    return View();  // ...or specify a view name, e.g. return View("SomeNamedView");
}

<%: ViewData["message"] %>, world!
The person's name is <%: ((Person)ViewData["person"]).Name %>
The person's age is <%: ((Person)ViewData["person"]).Age %>

Sending a Strongly Typed Object in ViewData.Model

ViewDataDictionary has a special property called Model. You can assign any.NET object to that property by writing ViewData.Model = myObject; in your action method, or as a shortcut you can pass myObject as a parameter to View()—for example:

public ViewResult ShowPersonDetails()
{
    Person someguy = new Person { Name = "Steve", Age = 108 };
    return View(someguy); // Implicitly assigns 'someguy' to ViewData.Model
    // ... or specify a view name, e.g. return View(someguy,"SomeNamedView");
}

Now you can access ViewData.Model in the view template:

The person's name is <%: ((Person)Model).Name %>
The person's age is <%: ((Person)Model).Age %>

Note

In a view template, you can write Model as a shorthand way of referencing ViewData.Model. However, code in an action method must refer to the object as ViewData.Model.

But hang on, that's hardly an improvement. We've given up the flexibility of passing multiple objects in a dictionary, and still have to do ugly typecasts. The real benefit arrives when you use a strongly typed view page.

I'll discuss the meaning and technical implementation of strongly typed views in some detail in Chapter 11—here I'll just give the overview. When you create a new view template (right-click inside an action method, and then choose Add View), you're given the option to create a strongly typed view by specifying what type of model object you want to render. The type you choose determines the type of the view's Model property. If you choose the type Person, you'll no longer need the ugly typecasts on Model, and you'll get IntelliSense (see Figure 9-2).

Figure 9-2. Strongly typed view data allows for IntelliSense while editing a view template

As a C# programmer, you no doubt appreciate the benefits of strong typing. The drawback, though, is that you're limited to sending only one object in ViewData.Model, which is awkward if you want to display a few status messages or other values at the same time as your Person object. To send multiple strongly typed objects, you'll need to create a wrapper class—for example:

public class ShowPersonViewModel
{
    public Person Person { get; set; }
    public string StatusMessage { get; set; }
    public int CurrentPageNumber { get; set; }
}

and then use this as the model type for a strongly typed view. Model classes that exist only to send particular combinations of data from a controller to a view (like ShowPersonViewModel) are often called view models to distinguish them from domain models.

public ViewResult ShowPersonDetails()
{
    Person someguy = new Person { Name = "Steve", Age = 108 };
    ViewData["message"] = "Hello";
    ViewData["currentPageNumber"] = 6;
    return View(someguy); // Implicitly assigns 'someguy' to ViewData.Model
    // or specify an explicit view name, e.g. return View(someguy,"SomeNamedView");
}

<%: ViewData["message"] %>, world!
The person's name is <%: Model.Name %>
The person's age is <%: Model.Age %>
You're on page <%: ViewData["currentPageNumber"] %>

public ViewResult ShowPersonDetails()
{
    dynamic model = new ExpandoObject();
    model.Message = "Hello";
    model.Person = new Person { Name = "Steve", Age = 108 };
    return View(model);
}

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<dynamic>" %>
<%: Model.Message %>, world!
The person's name is <%: Model.Person.Name %>
The person's age is <%: Model.Person.Age %>

As you've just seen, you can redirect to a different action method as easily as this:

return RedirectToAction("SomeAction");

This returns a RedirectToRouteResult object, which internally uses the routing system's outbound URL-generation features to determine the target URL according to your routing configuration.

If you don't specify a controller (as previously), it's understood to mean "on the same controller," but you can also specify an explicit controller name, and if you wish, you can supply other arbitrary custom routing parameters that affect the URL generated:

return RedirectToAction("Index", "Products", new { color = "Red", page = 2 } );

As always, under the MVC Framework's naming convention, you should just give the controller's routing name (e.g., Products), not its class name (e.g., ProductsController).

Finally, if you're working with named RouteTable.Route entries, you can nominate them by name:

return RedirectToRoute("MyNamedRoute", new { customParam = "SomeValue" });

These URL-generating redirection methods, their many overloads, and how they actually generate URLs according to your routing configuration, were explained in detail in Chapter 8.

If you want to redirect to a literal URL (not using outbound URL generation), then return a RedirectResult object by calling Redirect():

return Redirect("http://www.example.com");

You can use application-relative virtual paths, too:

return Redirect("~/Some/Url/In/My/Application");

A redirection causes the browser to submit a totally new HTTP request. So, in the new request, you'll no longer have the same set of request context values, nor access to any other temporary objects you created before the redirection. What if you want to preserve some data across the redirection? Then you should use TempData.

TempData is a new concept introduced with ASP.NET MVC^[62]—there's nothing quite like it in ASP.NET Web Forms. Like the Session collection, it stores arbitrary .NET objects for the current visitor, but unlike Session, it automatically removes items from the collection after you read them back. That makes it ideal for short-term data storage across a redirection.

Let's go back to the previous example with SaveRecord and Index. After saving a record, it's polite to confirm to the user that their changes were accepted and stored. But how can the Index() action method know what happened on the previous request? Use TempData like this:

public RedirectToRouteResult SaveRecord(int itemId, string newName)
{
    // Get the domain model to save the data
    DomainModel.SaveUpdatedRecord(itemId, newName);

    // Now redirect to the grid of all items, putting a status message in TempData
    TempData["message"] = "Your changes to " + newName + " have been saved";

return RedirectToAction("Index");
}

Then during the subsequent request, in Index's view, render that value:

<% if(TempData["message"] != null) { %>
    <div class="StatusMessage"><%: TempData["message"] %></div>
<% } %>

Before TempData, the traditional way to do this was to pass the status message as a query string value when performing the redirection. However, TempData is much better: it doesn't result in a massive, ugly URL, and it can store any arbitrary .NET object.

string messageValue = (string) TempData.Peek("message"); // Does not cause ejection

TempData.Keep("message"); // Ensures "message" won't get ejected after this request

As an example of using ContentResult, see how easy it is to create an RSS 2.0 feed. You can construct an XML document using the elegant .NET 3.5 XDocument API, and then send it to the browser using Content()—for example:

class Story { public string Title, Url, Description; }

public ContentResult RSSFeed()
{
    Story[] stories = GetAllStories(); // Fetch them from the database or wherever

    // Build the RSS feed document
    string encoding = Response.ContentEncoding.WebName;
    XDocument rss = new XDocument(new XDeclaration("1.0", encoding, "yes"),
        new XElement("rss", new XAttribute("version", "2.0"),
            new XElement("channel", new XElement("title", "Example RSS 2.0 feed"),
                from story in stories
                select new XElement("item",
                      new XElement("title", story.Title),
                      new XElement("description", story.Description),
                      new XElement("link", story.Url)
                   )
            )

)
    );

    return Content(rss.ToString(), "application/rss+xml");
}

Most modern web browsers recognize application/rss+xml and display the feed in a well-presented human-readable format, or offer to add it to the user's RSS feed reader as a new subscription.

You can use File() to send a file directly from disk as follows:

public FilePathResult DownloadReport()
{
    string filename = @"c:filessomefile.pdf";
    return File(filename, "application/pdf", "AnnualReport.pdf");
}

This will cause the browser to open a save-or-open prompt, as shown in Figure 9-4.

Figure 9-4. Internet Explorer's save-or-open prompt

This overload of File() accepts the parameters listed in Table 9-3.

If you omit fileDownloadName and the browser knows how to display your specified MIME type itself (e.g., all browsers know how to display an image/gif file), then the browser should simply display the file itself.

If you omit fileDownloadName and the browser doesn't know how to display your specified MIME type itself (e.g., if you specify application/vnd.ms-excel), then the browser should pop up a save-or-open prompt, guessing a suitable file name based on the current URL (and in Internet Explorer's case, based on the MIME type you've specified). However, the guessed file name will almost certainly make no sense to the user, as it may have an unrelated file name extension such as .mvc, or no extension at all. So, always be sure to specify fileDownloadName when you expect a save-or-open prompt to appear.

If you've already got the binary data in memory, you can transmit it using a different overload of File():

public FileContentResult DownloadReport()
{
    byte[] data = ... // Generate or fetch the file contents somehow
    return File(data, "application/pdf", "AnnualReport.pdf");
}

We used this technique at the end of Chapter 6 when sending image data retrieved from the database.

Again, you must specify a contentType, and you may optionally specify a fileDownloadName. The browser will treat these in exactly the same way as described previously.

Finally, if the data you want to transmit comes from an open System.IO.Stream, you don't have to read it all into memory before sending it back out as a byte array. Instead, you can tell File() to transmit the stream's data as each chunk becomes available:

public FileStreamResult ProxyExampleDotCom()
{
    WebClient wc = new WebClient();
    Stream stream = wc.OpenRead("http://www.example.com/");
    return File(stream, "text/html");
}

Once again, you must specify a contentType parameter and optionally may specify a fileDownloadName. The browser will treat these exactly the same way as described previously.

As a quick diversion, imagine you're building a stock photography-sharing web site. You might frequently need to process image files in various ways, and in particular you might have a number of action methods that return images with text superimposed on to them. This watermark text might be generated dynamically, sometimes stating the name of the photographer, and at other times the price of the image or its licensing details.

If you're writing unit tests for action methods that do this, how will the unit tests be able to check that the correct text was superimposed? Will they invoke the action method, get back the image data, and then use some kind of optical character recognition library to determine what string was superimposed? That might be fun to try, but frankly, it would be madness.

The way to solve this is to introduce a unit testability seam: a gap between the application code that decides what text to superimpose and the remaining code that actually renders the chosen text on to the image data. Your unit tests can squeeze into that gap, only testing the part of the code that decides what text to superimpose, ignoring the untestable part that actually renders text onto the image.

A custom action result is a great way to implement such a unit testability seam, because it allows your action method to specify what it intends to do, without the dirty business of actually doing it. Also, a custom action result makes the watermarking behavior easy to reuse across multiple action methods.

OK, enough discussion—here's the code! The following custom action result overlays some watermark text onto an image, and then transmits the image in PNG format (regardless of what format it started in):

public class WatermarkedImageResult : ActionResult
{
    public string ImageFileName { get; private set; }
    public string WatermarkText { get; private set; }

    public WatermarkedImageResult(string imageFileName, string watermarkText)
    {
        ImageFileName = imageFileName;
        WatermarkText = watermarkText;
    }

    public override void ExecuteResult(ControllerContext context)
    {
        using(var image = Image.FromFile(ImageFileName))
        using(var graphics = Graphics.FromImage(image))
        using(var font = new Font("Arial", 10))
        using(var memoryStream = new MemoryStream())
        {
            // Render the watermark text in bottom-left corner
            var textSize = graphics.MeasureString(WatermarkText, font);
            graphics.DrawString(WatermarkText, font, Brushes.White, 10,

image.Height - textSize.Height − 10);

            // Transmit the image in PNG format (note: must buffer it in
            // memory first due to GDI+ limitation)
            image.Save(memoryStream, ImageFormat.Png);
            var response = context.RequestContext.HttpContext.Response;
            response.ContentType = "image/png";
            response.BinaryWrite(memoryStream.GetBuffer());
        }
    }
}

Using this, you could overlay a timestamp onto an image using an action method, as follows:

public class WatermarkController : Controller
{
    private static string ImagesDirectory = @"c:images";

    public WatermarkedImageResult GetImage(string fileName)
    {
        // For security, only allow image files from a specific directory
        var fullPath = Path.Combine(ImagesDirectory, Path.GetFileName(fileName));

        string watermarkText = "The time is " + DateTime.Now.ToShortTimeString();
        return new WatermarkedImageResult(fullPath, watermarkText);
    }
}

Then display a watermarked image by putting a suitable <img> tag into a view template, as follows:

<img src="<%: Url.Action("GetImage", "Watermark", new {fileName="lemur.jpeg"})%>"/>

This will produce an image such as that shown in Figure 9-5.

Figure 9-5. Displaying an image with a timestamp watermark

To unit test WatermarkController's GetImage() method, you can write a test that invokes the method, gets the resulting WatermarkedImageResult, and then checks its ImageFileName and WatermarkText properties to see what text is going to be superimposed onto which image file.

Of course, in a real project, you would probably make the code a little more general purpose (instead of hard-coding the font name, size, color, and directory name).

If your action method uses ViewData—for example:

public ViewResult ShowAge(DateTime birthDate)
{
    // Compute age in full years
    DateTime now = DateTime.Now;
    int age = now.Year - birthDate.Year;
    if((now.Month*100 + now.Day) < (birthDate.Month*100 + birthDate.Day))
        age -= 1; // Haven't had birthday yet this year

    ViewData["age"] = age;

return View();
}

then you can test its contents, too:

[Test]
public void ShowAge_WhenBornSixYearsTwoDaysAgo_DisplaysAge6()
{
    // Arrange
    SimpleController controller = new SimpleController();
    DateTime birthDate = DateTime.Now.AddYears(−6).AddDays(−2);

    // Act
    ViewResult result = controller.ShowAge(birthDate);

    // Assert
    Assert.AreEqual(6, result.ViewData["age"], "Showing wrong age");
}

If your action method passes a strongly typed Model object to the view, then the unit test can find that value at result.ViewData.Model. Note that result.ViewData.Model is of type object, so you'll need to cast it to the expected model type.

You can factor out much of the logic needed to mock ASP.NET MVC's runtime context so that you can reuse it from one unit test to the next. Each individual unit test can then be much simpler. The way to do this is to define HttpContext, Request, Response, and other context objects, plus the relationships between them, using the API of your chosen mocking tool. If you're using Moq, the following reusable utility class (downloadable from this book's page on the Apress web site) does the job:

public class ContextMocks
{
    public Moq.Mock<HttpContextBase> HttpContext { get; private set; }
    public Moq.Mock<HttpRequestBase> Request { get; private set; }
    public Moq.Mock<HttpResponseBase> Response { get; private set; }
    public RouteData RouteData { get; private set; }

    public ContextMocks(Controller onController)
    {
        // Define all the common context objects, plus relationships between them
        HttpContext = new Moq.Mock<HttpContextBase>();
        Request = new Moq.Mock<HttpRequestBase>();
        Response = new Moq.Mock<HttpResponseBase>();
        HttpContext.Setup(x => x.Request).Returns(Request.Object);
        HttpContext.Setup(x => x.Response).Returns(Response.Object);
        HttpContext.Setup(x => x.Session).Returns(new FakeSessionState());

Request.Setup(x => x.Cookies).Returns(new HttpCookieCollection());
        Response.Setup(x => x.Cookies).Returns(new HttpCookieCollection());
        Request.Setup(x => x.QueryString).Returns(new NameValueCollection());
        Request.Setup(x => x.Form).Returns(new NameValueCollection());

        // Apply the mock context to the supplied controller instance
        RequestContext rc = new RequestContext(HttpContext.Object, new RouteData());
        onController.ControllerContext = new ControllerContext(rc, onController);
    }
    // Use a fake HttpSessionStateBase, because it's hard to mock it with Moq
    private class FakeSessionState : HttpSessionStateBase
    {
        Dictionary<string, object> items = new Dictionary<string, object>();
        public override object this[string name]
        {
            get { return items.ContainsKey(name) ? items[name] : null; }
            set { items[name] = value; }
        }
    }
}

Using the ContextMocks utility class, you can simplify the previous unit test as follows:

[Test]
public void Homepage_Recognizes_New_Visitor_And_Sets_Cookie()
{
    // Arrange
    var controller = new SimpleController();
    var mocks = new ContextMocks(controller); // Sets up complete mock context

    // Act
    ViewResult result = controller.Homepage();

    // Assert
    Assert.IsEmpty(result.ViewName);
    Assert.IsTrue((bool)result.ViewData["IsFirstVisit"]);
    Assert.AreEqual(1, controller.Response.Cookies.Count);
    Assert.AreEqual(bool.TrueString,
                    controller.Response.Cookies["HasVisitedBefore"].Value);
}

That's much, much more readable. Of course, if you're testing the action's behavior for a new visitor, you should also test its behavior for a returning visitor:

[Test]
public void Homepage_Recognizes_Previous_Visitor()
{
    // Arrange
    var controller = new SimpleController();
    var mocks = new ContextMocks(controller);
    controller.Request.Cookies.Add(new HttpCookie("HasVisitedBefore",
                                                  bool.TrueString));

    // Act
    ViewResult result = controller.Homepage();

    // Assert (this time, demonstrating NUnit's alternative "constraint" syntax)
    Assert.That(result.ViewName, Is.EqualTo("HomePage") | Is.Empty);
    Assert.That((bool)result.ViewData["IsFirstVisit"], Is.False);
}

You can also use the ContextMocks object to simulate extra conditions during the arrange phase (e.g., mocks.Request.Setup(x => x.HttpMethod).Returns("POST")).

Sometimes it's helpful to decouple a controller from its external context by encapsulating all access to external context objects inside virtual properties or methods. At runtime, these virtual properties or methods will be called as normal, but in unit tests, you can mock their return values.

This is easiest to understand with an example. You could refactor the Homepage() action method from the previous example as follows:

public ViewResult Homepage()
{
    if (IncomingHasVisitedBeforeCookie == null)
    {
        ViewData["IsFirstVisit"] = true;
        // Set the cookie so we'll remember the visitor next time
        OutgoingHasVisitedBeforeCookie = new HttpCookie("HasVisitedBefore", "True");
    }
    else

ViewData["IsFirstVisit"] = false;

    return View();
}

public virtual HttpCookie IncomingHasVisitedBeforeCookie
{
    get { return Request.Cookies["HasVisitedBefore"]; }
}
public virtual HttpCookie OutgoingHasVisitedBeforeCookie
{
    get { return Response.Cookies["HasVisitedBefore"]; }
    set
    {
        Response.Cookies.Remove("HasVisitedBefore");
        Response.Cookies.Add(value);
    }
}

Note that the behavior is unaffected; the previous unit tests will still pass. The difference is that instead of touching Request and Response directly, our action method now accesses context information through virtual properties.

You can then write a unit test without a large number of mocks, directly intercepting any calls to IncomingHasVisitedBeforeCookie and OutgoingHasVisitedBeforeCookie.

[Test]
public void Homepage_Recognizes_New_Visitor_And_Sets_Cookie()
{
    // Arrange
    var controller = new Moq.Mock<SimpleController> { CallBase = true };
    controller.Setup(x => x.IncomingHasVisitedBeforeCookie)
              .Returns((HttpCookie)null);
    controller.SetupProperty(x => x.OutgoingHasVisitedBeforeCookie);

    // Act
    ViewResult result = controller.Object.Homepage();

    // Assert
    Assert.IsEmpty(result.ViewName);
    Assert.IsTrue((bool)result.ViewData["IsFirstVisit"]);
    Assert.AreEqual("True", controller.Object.OutgoingHasVisitedBeforeCookie.Value);
}

First notice that this time we have actually mocked the controller instance itself, using Moq's CallBase = true option to specify that any methods and properties not specifically overridden should behave as normal and call a real controller instance as they would at runtime.

Then, we've specifically told Moq to override the IncomingHasVisitedBeforeCookie property so that it always returns null, and to treat OutgoingHasVisitedBeforeCookie as a simple property that merely stores and returns any values set to it. Finally, we can make an assertion about the value written to OutgoingHasVisitedBeforeCookie. Moq is able to override these properties because they are both marked as virtual.

This technique can significantly reduce the complexity of working with external context objects, because you can choose exactly where it's convenient to draw a boundary between the controller and the other objects it must access. One possible drawback is that if you measure unit test code coverage, this will come out as less than 100 percent because the mocked properties and methods won't be run during unit tests. So, you should only use the technique if your mocked virtual properties and methods can be kept very simple.

As you saw in the SportsStore example in Chapter 5 (under the heading "Giving Each Visitor a Separate Shopping Cart"), it's possible to use the MVC Framework's model binding system to populate action method parameters using arbitrary logic. In the SportsStore example, we used this technique to supply Cart instances from the Session collection.

Having done this, it's trivial to write a unit test that invokes an action method, passing a Cart object as a parameter as if the model binder had supplied that object. For example, you could test that CartController's Index action sets ViewData.Model to be the current user's cart:

[Test]
public void Index_DisplaysCurrentUsersCart()
{
    // Arrange
    Cart currentUserCart = new Cart();
    CartController controller = new CartController(null);

    // Act
    ViewResult result = controller.Index(currentUserCart, "someReturnUrl");

    // Assert
    Assert.AreSame(currentUserCart, result.ViewData.Model);
}

Notice that this unit test doesn't need to mock Request or Response or simulate Session in any way (even though at runtime the Cart would come from Session), because the action method acts only on its parameters. You could take any collection of context information relevant to your application, model it as a .NET class, and then create a custom binder that can supply these instances to any action method requiring a parameter of that type.

As an alternative to using a custom model binder as a way of supplying context objects to a controller, you could also model them as .NET interfaces and supply concrete instances at runtime using your DI container.

This doesn't eliminate mocking—your unit tests would now have to mock the new interface you had just created—but it could simplify and reduce it. Your interfaces would describe the context data in a convenient way for the controller to consume, so they would no longer need to mock HttpContext, Request, Session, Cookies, and so on.

This final suggestion brings up broader matters of development methodology and object-oriented design. Over the past few years, many of the best practices and lessons learned from TDD have been collected, refined, and given the name behavior-driven development (BDD). The key observation of BDD is that it's more useful to drive your development process by specifying the behaviors you want to see rather than how those behaviors should be implemented.

For UI code, which for us means controllers in ASP.NET MVC, many behaviors aren't observable in a single call to an action method—they're only observable when the actions, your views, your JavaScript, the user's browser, your routing configuration, and other back-end components are all working together across a series of HTTP requests. Behaviors such as, "If I enter the wrong password too many times, I am no longer allowed to log in" exist only through the interactions across your whole technology stack. By the nature of UI code, the only complete way to specify and automatically verify such behaviors is typically by using UI automation tools (such as WatiN, as described in Chapter 3).

What does this mean for unit testing? Unit testing works brilliantly for back-end code such as services and domain classes because this is often where your complex business logic lives, and because such code tends to have a constrained range of inputs and outputs, so it's naturally easy to unit test. TDD has proven its benefits over and over both for designing and for verifying this type of code.

You could also choose to unit test your UI code (MVC controllers and action methods). But assuming you've factored any significant complexity out into separately tested service and domain classes, unit tests for your simple action methods would be more complex than the action methods themselves, and therefore wouldn't aid their design. Plus, UI automation tests can give you a high level of confidence that the whole system works together, and they detect newly introduced bugs better than action method unit tests ever could. Overall, this is why many in the ASP.NET MVC community have started focusing on BDD-style UI automation testing, and making controller unit testing the exception rather than the rule.

Whatever methodology you choose, make sure that you and your colleagues at least understand how to make use of unit testing, because it's an immensely useful technique when developing many parts of your application, and this is likely to include unit testing controllers from time to time.