New to The Big Boy MVC Series?
Read the series from its humble beginnings.

We’re getting pretty close to having a functioning (albeit ugly) website. If you’re starting to get confused, or angry, or whiny, try to hang in there. My advice is always this: if you don’t understand what’s going on, just copy and paste it into your project. Fiddle with it. Break it. Soon enough, you’ll enjoy the invigorating feeling of deep understanding. And, when that feeling comes, you’ll never want to leave the Microsoft stack ever again. Or, you can always try out Ruby on Rails.

Today, we have a pretty simple task. We’ve created our repository. We’ve also created our controllers. It’s time for the two to meet. Like turtles. In a dark closet.

When using our repository in a controller, we want to follow a few simple (opinionated) guidelines:

1. For easy testing, we’ll want to be able to inject a mock repository into our controller whenever we feel like it. Hence, we’ll follow the IOC pattern.
2. If a particular ActionResult does not require that we create a DataContext, a DataContext shouldn’t be created. This rule is broken by developers more often than you might expect.
3. Our controller is a drama queen. So, our repository should make the life of our controller as easy as possible. If we ever catch ourselves doing too much work in our controller to transform repository data, we probably have an inadequacy in our repository that we need to fix.
4. As a sidenote, when we’re updating data (i.e. the CUD in CRUD), we should follow the Post-Redirect-Get Pattern.

Alright. Time to get crackin’!

Step 1: Add some code to the TestInit method in your FoodControllerTest class. Since all of our data is related to Food, we’re definitely going to need access to our repository inside of our FoodController. Hence, let’s redesign our FoodController (via TDD) so that it follows the IOC pattern mentioned in our opinionated guidelines.

using System.Web.Routing;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using MvcContrib.TestHelper;
using Big.Fat.Dish.Controllers;
using Big.Fat.Dish.Models;
using Rhino.Mocks;
using System.Web.Mvc;

namespace Big.Fat.Dish.Tests.Controllers
{
    [TestClass]
    public class FoodControllerTest
    {
        MockRepository mocks;
        IRepository repo;
        FoodController foodController;

        [TestInitialize]
        public void TestInit()
        {
            mocks = new MockRepository();
            repo = mocks.DynamicMock<IRepository>();
            foodController = new FoodController(repo); //here's the repo injection

            MvcApplication.RegisterRoutes(RouteTable.Routes);
            mocks.ReplayAll();
        }

        //... we're only changing the Food constructor, so...
        //... unit tests, etc. omitted for the sake of brevity ...
    }
}

With the IOC pattern in place, we’ll be able to inject a mock repository into our controller. We can then verify that our controller is invoking the correct repository method (or methods) without actually having to invoke the method (or methods) on a real repository class. Good times.

Step 2: Try to compile. Feel the fail.. Our controller doesn’t follow the IOC pattern yet. That’s okay. We expected that. To fix the “error”, we need to follow the compiler’s instructions–namely, we need to create a FoodController constructor that takes an IRepository as a parameter:

using System.Web.Mvc;
using Big.Fat.Dish.Models;

namespace Big.Fat.Dish.Controllers
{
    public class FoodController : Controller
    {
        IRepository repo;

        public FoodController() : this(null) { } //I'll explain this null parameter later
        public FoodController(IRepository repo)
        {
            this.repo = repo;
        }

        //...
    }
}

Step 3: Setup lazy loading for our repository. With lazy loading, our repository class (and thus our DataContext class) will only be instantiated when the repository is beckoned in a controller method:

using System.Web.Mvc;
using Big.Fat.Dish.Models;

namespace Big.Fat.Dish.Controllers
{
    public class FoodController : Controller
    {
        IRepository lazyRepo;
        IRepository repo
        {
            get
            {
                if (lazyRepo == null)
                {
                    lazyRepo = new Repository();
                }

                return lazyRepo;
            }
        }

        public FoodController() : this(null) { }  //no need to create a repo yet...
        public FoodController(IRepository repo)
        {
            this.lazyRepo = repo;
        }

        //...
    }
}

Step 4: Create unit tests for the Add Food postback method. When a user submits an Add Food Form on the Add Food page, we want that post request to be intercepted by a method (not yet created) in our FoodController. That method will have a Food class as a parameter, and (here’s the real MVC kicker) that Food class will contain all of the field values from the form submitted by the user. We’ll talk more about this form magic in a later post. I promise.

When testing our Add Food post method, then, we’ll want to verify that

1. repo.Add() is called.
2. repo.Save() is called.
3. neither repo.Add() nor repo.Save() is called if a validation error occurs.
4. the user is redirected to the Food Added page if the post was a success.
5. the user is redirected back to the Add Food page if the post was a failure.

Let’s go ahead and write all of the tests. Here’s our updated FoodControllerTest class in its entirety:

using System.Web.Routing;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using MvcContrib.TestHelper;
using Big.Fat.Dish.Controllers;
using Big.Fat.Dish.Models;
using Rhino.Mocks;
using System.Web.Mvc;

namespace Big.Fat.Dish.Tests.Controllers
{
    [TestClass]
    public class FoodControllerTest
    {
        MockRepository mocks;
        IRepository repo;
        FoodController foodController;
        Food food;

        [TestInitialize]
        public void TestInit()
        {
            mocks = new MockRepository();
            repo = mocks.DynamicMock<IRepository>();
            foodController = new FoodController(repo);
            food = new Food();

            MvcApplication.RegisterRoutes(RouteTable.Routes);
            mocks.ReplayAll();
        }

        [TestCleanup]
        public void TestCleanup()
        {
            RouteTable.Routes.Clear();
        }

        [TestMethod]
        public void Controllers_Food_AddFoodUrl_Maps_To_FoodController()
        {
            "~/add/food/".Route().ShouldMapTo();
        }

        [TestMethod]
        public void Controllers_Food_AddFoodUrl_Maps_To_Food_Add_Action()
        {
            "~/add/food/".Route().ShouldMapTo(n => n.Add());
        }

        [TestMethod]
        public void Controllers_Food_FoodAddedUrl_Maps_To_FoodController()
        {
            "~/food/added/100".Route().ShouldMapTo();
        }

        [TestMethod]
        public void Controllers_Food_FoodAddedUrl_Maps_To_Food_Added_Action()
        {
            "~/food/added/100".Route().ShouldMapTo(n => n.Added(100));
        }

        [TestMethod]
        public void Controllers_Food_FoodDetailsUrl_Maps_To_FoodController()
        {
            "~/wa/seattle/ettas/100/salmon-on-cherrywood-plank/".Route().ShouldMapTo();
        }

        [TestMethod]
        public void Controllers_Food_FoodDetailsUrl_Maps_To_Food_Details_Action()
        {
            "~/wa/seattle/ettas/100/salmon-on-cherrywood-plank/".ShouldMapTo(n => n.Details(100));
        }

        [TestMethod]
        public void Controllers_Food_Post_Calls_Repository_Add()
        {
            repo.Expect(r => r.Add(food));
            foodController.Add(food);
            mocks.VerifyAll();
        }

        [TestMethod]
        public void Controllers_Food_Post_Calls_Repository_Save()
        {
            repo.Expect(r => r.Save());
            foodController.Add(food);
            mocks.VerifyAll();
        }

        [TestMethod]
        public void Controllers_Food_Post_Does_Not_Call_Repository_On_ModelState_Error()
        {
            repo.Expect(r => r.Add(food)).Repeat.Never();
            repo.Expect(r => r.Save()).Repeat.Never();
            foodController.ModelState.AddModelError("Name", "Food Name is required");
            foodController.Add(new Food());
            mocks.VerifyAll();
        }

        [TestMethod]
        public void Controllers_Food_Post_Redirect()
        {
            ActionResult result = foodController.Add(food);
            Assert.IsInstanceOfType(result, typeof(RedirectToRouteResult));
        }

        [TestMethod]
        public void Controllers_Food_Post_Redirects_To_Food_Added_On_Success()
        {
            var result = foodController.Add(food) as RedirectToRouteResult;
            var routeVals = result.RouteValues;
            Assert.AreEqual("Added", routeVals["action"]);
        }

        [TestMethod]
        public void Controllers_Food_Post_Redirects_To_Food_Add_On_Error()
        {
            foodController.ModelState.AddModelError("Name", "Food Name is required");
            var result = foodController.Add(food) as RedirectToRouteResult;
            var routeVals = result.RouteValues;
            Assert.AreEqual("Add", routeVals["action"]);
        }
    }
}

Step 5: Try to compile. Feel the fail. Looks like it’s time to create our Add Food post method in our FoodController class. Here’s our updated FoodController class in its entirety:

using System;
using System.Web;
using System.Web.Mvc;
using System.Linq.Expressions;
using Big.Fat.Dish.Models;

namespace Big.Fat.Dish.Controllers
{
    public class FoodController : Controller
    {
        IRepository lazyRepo;
        IRepository repo
        {
            get
            {
                if (lazyRepo == null)
                {
                    lazyRepo = new Repository();
                }

                return lazyRepo;
            }
        }

        public FoodController() : this(null) { }
        public FoodController(IRepository repo)
        {
            this.lazyRepo = repo;
        }

        public ActionResult Index()
        {
            return View();
        }

        [HttpGet]
        public ActionResult Add()
        {
            return View();
        }

        [HttpPost]
        public ActionResult Add(Food food)
        {
            if (!ModelState.IsValid)
            {
                //TODO: add error message
                return RedirectToAction("Add");
            }

            this.repo.Add(food);
            this.repo.Save();

            //note: I changed FoodId to Id (in db table and dbml file)
            return RedirectToAction("Added", new { id = food.Id });
        }

        public ActionResult Added(int id)
        {
            return View();
        }

        public ActionResult Details(int id)
        {
            return View();
        }
    }
}

Step 6: Run your unit tests. Feel the breeze in your underpants. We now have a post method in our FoodController that passes all of our unit tests.

That’s it for now.

Tomorrow, we’ll start by cleaning up the actual Add Food page. Then, we’ll get to watch our first successful postback. And, finally, after a wee bit of fireworks and a quick delusional spike in self-esteem, we’ll get right back to work. We’ve only got a couple weeks left to ship this monkey!

Move on to Part 22: Mistakes Make Me Human. Fixing Mistakes Makes Me Brad Wilson.

Read More

• The Big Boy MVC Series — Part 26: It’s Codeplex Time! (7)
  You've sucked all the blood out of me. Hence, the bottomless silence. That said, I've finished creating a working version of Big Fat Dish. Joy almigh...
• The Big Boy MVC Series — Part 25, Going Postal: ActionFilters, Moq, ModelState, Oh My! (8)
  The Bad News: I'm behind schedule. I wanted to finish this project in a month, and, if you've been paying close attention to the time I've wasted fidd...
• The Big Boy MVC Series — Part 24: Dear EditorTemplates, Are We Done Posting Yet? (6)
  When we talk about "improving" our skills as knowledge-hungry developers, I find it interesting that we rarely mention the people in our lives (not Ka...