Question

I’m a bit lost as to how unit tests could tie in to my current project’s design. My current tests are all integration tests which end up pretty much just testing the third party ORM. I was thinking I needed to use the Repository pattern but its not clear to me how exactly how to add that as a layer in my application. Here is a basic object I am working with for an example:

public class Venue : ModelBase<Venue>
{
    public Venue ()
        : base()
    {
    }

    public virtual string VenueName { get; set; }
}

And its actions:

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

    public ActionResult Create ([ModelBinder(typeof(VenueBinder))]Venue Venue)
    {
        Venue.Save();
        return RedirectToAction("List", "Venue");
    }

    [HttpGet]
    public ActionResult Edit (long id) 
    {
        return View(Venue.Load(id));    
    }

    [HttpPost]
    public ActionResult Edit ([ModelBinder(typeof(VenueBinder))]Venue v, long id)
    {
        VenueBinder.EditModel(v, id);
        return RedirectToAction("List", "Venue");
    }

    public ActionResult Delete (long id)
    {
        Venue temp = Venue.Load(id);
        var eventController = new EventController();
        foreach (var e in Event.All().ToList().FindAll(x => x.Venue.ID == id))
        {
            eventController.Delete(e.ID);
        }
        temp.Delete();
        return RedirectToAction("List", "Venue");

    }       

and model binder:

public class VenueBinder : IModelBinder
{
    /// <summary>
    /// bind form data to Venue model
    /// </summary>
    public object BindModel (ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        return new Venue
        {
            VenueName = bindingContext.ValueProvider.GetValue("name").AttemptedValue
        };
    }

    /// <summary>
    /// edits an existing Venue object
    /// </summary>
    public static void EditModel (Venue v, long id)
    {
        Venue temp = Venue.Load(id);
        temp.VenueName = v.VenueName;
        temp.Save();
    }
}

Answer 1

If you want to unit test your controller actions in isolation you will have to abstract the CRUD operations that could be performed on your model behind an interface that the controller will take as a constructor dependency. Inside the unit test you could provide a mocked instance of this interface to the controller and be able to define expectations on it.

This being said, too many abstractions are not always a good thing and you shouldn’t do it just for the sake of unit testing. If they don’t bring some other value to your site such as have for example a reusable repository layer in other applications you probably shouldn’t be doing it. Integration tests are also fine. You just need to ensure that you are doing it on a data that is in a predictable state for each test, ideally populated before each test and torn down after it. Hopefully your ORM supports this. Jimmy Bogard wrote a nice blog post on the subject of limiting your abstractions.