It is actually quire easy to unit test model validation. Models are inherently easy to test separately due to their POD (Plain Old Data) nature. We can instantiate them directly. Moreover, DataAnnotations provides us with the necessary interface to run the validation against a model object completely separately from the rest of the application.

A first model validation test class

Here is a basic model that we will unit test for the demonstration:

using System;
using System.ComponentModel.DataAnnotations;

namespace DataAnnotationsUnitTesting
{
    public class CreatePersonModel
    {
        [Required]
        public string FirstName { get; set; }
        [Required]
        public string LastName { get; set; }
        [Range(typeof (DateTime), "1900/01/01", "2000/01/01")]
        public DateTime BirthDate { get; set; }
        [RegularExpression(@"\+?\d+")]
        public string PhoneNumber { get; set; }
    }
}

As you can see, it is quite simple. We’ll go directly to the unit test implementation.

The strategy we are going to use consists in basing each test case on a valid model instance, then modifying it in such a way that it triggers one single validation error. We end up with a skeleton unit test class like this:

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using NUnit.Framework;

namespace DataAnnotationsUnitTesting {
    [TestFixture]
    public class CreatePersonModelValidationTests : AssertionHelper {
        private CreatePersonModel CreateValidPersonModel() {
            return new CreatePersonModel() {
                FirstName = "Some Name",
                LastName = "Some Last Name",
                BirthDate = new DateTime(1982, 07, 28),
                PhoneNumber = "+112233445566"
            };
        }

        public IEnumerable<ValidateRuleSpec> ValidationRule_Source() {
            yield break;
        }

        [Test]
        [TestCaseSource("ValidationRule_Source")]
        public void ValidationRule(ValidateRuleSpec spec) {
            // Arrange
            var model = CreateValidPersonModel();
            // Apply bad valud
            model.GetType().GetProperty(spec.MemberName).SetValue(model, spec.BadValue);

            // Act
            var validationResults = new List<ValidationResult>();
            var success = Validator.TryValidateObject(model, new ValidationContext(model), validationResults, true);

            // Assert
            Expect(success, False);
            Expect(validationResults.Count, EqualTo(1));
            Expect(validationResults.SingleOrDefault(r => r.MemberNames.Contains(spec.MemberName)), Not.Null);
        }

        public class ValidateRuleSpec {
            public object BadValue;
            public string MemberName;

            public override string ToString() {
                return MemberName + " - " + (BadValue ?? "<null>");
            }
        }
    }
}

Some explanation:

• ValidateRule() implements the test itself. However, it gets the specifications for each test via an argument. 
• ValidateRule_Source() provides the specs for our test.
• class ValidateRuleSpec holds the specifications. Its ToString() uses the spec values to render a distinct string per test. This makes unit test reports easy to read. In case of failure, you know exactly which spec failed.

And now the implementation of our ValidateRule_Source():

public IEnumerable<ValidateRuleSpec> ValidationRule_Source() {
    yield return new ValidateRuleSpec() {
        BadValue = null,
        MemberName = "FirstName"
    };
    yield return new ValidateRuleSpec() {
        BadValue = string.Empty,
        MemberName = "FirstName"
    };
    yield return new ValidateRuleSpec() {
        BadValue = null,
        MemberName = "LastName"
    };
    yield return new ValidateRuleSpec() {
        BadValue = string.Empty,
        MemberName = "LastName"
    };
    yield return new ValidateRuleSpec() {
        BadValue = new DateTime(),
        MemberName = "BirthDate"
    };
    yield return new ValidateRuleSpec() {
        BadValue = DateTime.Today,
        MemberName = "BirthDate"
    };
    yield return new ValidateRuleSpec() {
        BadValue = "-65623",
        MemberName = "PhoneNumber"
    };
    yield return new ValidateRuleSpec() {
        BadValue = "abc",
        MemberName = "PhoneNumber"
    };
}

Refining the solution

This works but can be improved. Most of the functionality can be abstracted. The actual test need only provide the valid model object and the specifications. A bit of refactoring yields a nicer design for our test:

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using NUnit.Framework;

namespace DataAnnotationsUnitTesting {
    [TestFixture]
    public abstract class ModelValidationTestsBase : AssertionHelper {
        protected abstract CreatePersonModel CreateValidModel();

        public abstract IEnumerable<ValidateRuleSpec> ValidationRule_Source();

        [Test]
        [TestCaseSource("ValidationRule_Source")]
        public void ValidationRule(ValidateRuleSpec spec) {
            // Arrange
            var model = CreateValidModel();
            // Apply bad valud
            model.GetType().GetProperty(spec.MemberName).SetValue(model, spec.BadValue);

            // Act
            var validationResults = new List<ValidationResult>();
            var success = Validator.TryValidateObject(model, new ValidationContext(model), validationResults, true);

            // Assert
            Expect(success, False);
            Expect(validationResults.Count, EqualTo(1));
            Expect(validationResults.SingleOrDefault(r => r.MemberNames.Contains(spec.MemberName)), Not.Null);
        }

        protected ValidateRuleSpec Spec(string memberName, object badValue) {
            return new ValidateRuleSpec() {MemberName = memberName, BadValue = badValue};
        }

        public class ValidateRuleSpec {
            public object BadValue;
            public string MemberName;

            public override string ToString() {
                return MemberName + " - " + (BadValue ?? "<null>");
            }
        }
    }

    public class CreatePersonModelValidationTests : ModelValidationTestsBase {
        protected override CreatePersonModel CreateValidModel() {
            return new CreatePersonModel() {
                FirstName = "Some Name",
                LastName = "Some Last Name",
                BirthDate = new DateTime(1982, 07, 28),
                PhoneNumber = "+112233445566"
            };
        }

        public override IEnumerable<ValidateRuleSpec> ValidationRule_Source() {
            yield return Spec("FirstName", null);
            yield return Spec("FirstName", string.Empty);
            yield return Spec("LastName", null);
            yield return Spec("LastName", string.Empty);
            yield return Spec("BirthDate", new DateTime());
            yield return Spec("BirthDate", DateTime.Today);
            yield return Spec("PhoneNumber", "-65623");
            yield return Spec("PhoneNumber", "abc");
        }
    }
}

Notice how we trimmed CreatePersonModelValidationTests to a minimum. The class ModelValidationTestsBase can now be used for most of our model validation unit tests.

What do you think?

ASP.Net MVC really pushes for loosely coupled components and as such, encourages unit testing. Your controllers are not much more than plain methods taking some input, executing some logic and returning an output. Your controller is not responsible for much in the end. Even though it is a central part of any functionality, its responsibility is reduced to implementing the logic for responding to a certain type of request. It relies on the framework configuration and conventions to call its methods in an appropriate way.

Understanding the extend of a controller’s responsibility is a key to writing good, concise unit tests. Sometimes, it’s easier to remember what it is not responsible for:

• Model binding: turning the encoded form data or routing information into .Net object. A controller action does not need to know and does not care that the id of the object your are updating is a part of your action’s path (eg.

  /admin/tags/edit/my-tag

   ) or if it is provided in the form of an encoded form field (eg.

  <input type="text" name="tagSlug" />

   )
• Model validation: it may seem surprising but in most cases, your controller should not implement the validation logic. From a controller’s action point of view, is there really a difference between a person’s last name missing or an unknown phone number format ? As far as your hypothetical EditPerson action is concerned, there is a validation error. Model validation should be tested separately.
• Pure business logic: a controller action is meant to handle requests. Even though it does not directly cope with http intricacies, it still very close to the http request/response life cycle. For example, an action ComputeLoanSchedule that needs to return a loan amortization schedule should probably delegate the actual computation to a business service class (ILoanService.GetAmortizationSchedule()) whose sole purpose is to handle such computation. In the future, if you need to expose the amortization schedule feature as a web api, you will only need to implement another controller and call the same business service.

In the end, your controller is only responsible for:

• Delegating work to domain services: as stated above, the domain logic of your application should be logically separated from your UI layer. It also gives you the flexibility to scale your web application and business domain services. 
• Returning an appropriate response: a controller’s action responds to a request by returning a response. The standard MVC Controller class expects your actions provide a result that will drive the way the response if created. eg. Returning a ViewResult will trigger view rendering and a RedirectToRouteResult may respond with an HTTP 302.

Unit testing a controller action

When it comes to unit testing, the less to test, the better. As such, the limited responsibility of controller actions is a boon when writing unit tests. As an example, I will be using a very simple controller

TagsController

TagsController

• Index: provides the user with a list of existing tags
• Create: enables the creation of new tags
• Edit: enables editing existing tags

The simple case

We will focus on the index functionality for now. It is implemented as a single action on our TagsController:

public class TagsController : Controller {
    private ITagService tagService;

    public TagsController(ITagService tagService) {
        this.tagService = tagService;
    }

    public ActionResult Index() {
        var tags = this.tagService.GetAll().OrderBy(tag => tag.Name);
        return View("Index", tags);
    }

    /* ... */
}

The TagsController constructor takes a ITagService. It provides our constructor access to the tags in our database. As you can see, the

Index()

With such a simple implementation, the unit test will be quite simple also. I’ll follow the usual AAA (Arrange-Act-Assert) pattern.

[Test]
public void Index_RetrievesAllTags() {
    // Arrange
    var mockService = new Mock<ITagService>();
    var controller = new TagsController(mockService.Object);
    mockService
        .Setup(s => s.GetAll())
        .Returns(new[] {
            new Tag {Slug = "tag1", Name = "Tag1"},
            new Tag {Slug = "tag7", Name = "Tag7"},
            new Tag {Slug = "tag4", Name = "Tag4"}
        });

    // Act
    var result = controller.Index() as ViewResult;

    // Assert
    Expect(result, Not.Null);
    Expect(result.ViewName, EqualTo("Index"));

    // ensure service was used
    mockService.Verify(s => s.GetAll(), Times.Once());

    // check view's model
    var tags = result.Model as IEnumerable<Tag>;
    Expect(tags, Not.Null);
    Expect(tags.Count(), EqualTo(3));
    // tags should be sorted
    Expect(tags.ToArray()[0].Slug, EqualTo("tag1"));
    Expect(tags.ToArray()[1].Slug, EqualTo("tag4"));
    Expect(tags.ToArray()[2].Slug, EqualTo("tag7"));
}

The first part sets up an ITagService mock for TagsController to consume. We then simply call method

Index()

The assertions start with making sure we got a non-null result of the ViewResult type.

Index()

mockService.Verify()

ITagService.GetAll()

I then proceed with checking the model provided to the view is consistent with the data from the mock service object. One of the requirements is that the tags are sorted by name.

As you can see in the Index unit test, there is a lot more code than the method being tested. This is also one of the reason why you should reduce the scope of your tests as much as you can.

A more complex test case

I’ll cover the “create a new tag” functionality. In this case, the functionality is implemented by a pair of actions. A parameter-less

Create()

Create()

SaveTagModel

public class TagsController : Controller
{
    /* ... */

    [HttpGet]
    public ActionResult Create() {
        return View("Save", new SaveTagModel() {IsNew = true});
    }

    [HttpPost]
    public ActionResult Create(SaveTagModel saveTagModel) {
        var existingTag = tagService.GetBySlug(saveTagModel.Slug);
        if (existingTag != null) {
            ModelState.AddModelError("TagExists", "A tag with that slug already exists");
        }

        if (!ModelState.IsValid) {
            saveTagModel.IsNew = true;
            return View("Save", saveTagModel);
        }

        tagService.Save(new Tag() { Name = saveTagModel.Name, Slug = saveTagModel.Slug });
        return RedirectToAction("Index");
    }

    /* ... */
}

I’ll show the tests I put together to cover the functionality of

TagsController.Create()

Create()

Edit()

SaveTagModel

[Test]
public void Create_ShowsEmptySaveEditor() {
    // Arrange
    var mockService = new Mock<ITagService>();
    var controller = new TagsController(mockService.Object);

    // Act
    var result = controller.Create() as ViewResult;

    //Assert
    Expect(result, Not.Null);
    Expect(result.ViewName, EqualTo("Save"));
    var saveTagModel = result.Model as SaveTagModel;
    Expect(saveTagModel, Not.Null);
    Expect(saveTagModel.IsNew, True);
    Expect(saveTagModel.Name, Null.Or.Empty);
    Expect(saveTagModel.Slug, Null.Or.Empty);
}

The next 2 tests cover the behavior of the

Create(SaveTagModel tag)

• What happens when invalid input is provided?
• What happens when a tag exists with the same ‘slug’?
• What happens upon success?

It will not come as a surprise that I wrote 3 tests, one for each of the points. The first test ensure

Create()

[Test]
public void Create_ShowsEditorAgainOnInvalidInput() {
    // Arrange
    var mockService = new Mock<ITagService>();
    var controller = new TagsController(mockService.Object);

    // Act
    var saveTagModelArg = new SaveTagModel() {Slug = string.Empty, Name = "somename"};
    controller.ModelState.AddModelError("testerror", "test message");
    var result = controller.Create(saveTagModelArg) as ViewResult;

    //Assert
    Expect(result, Not.Null);
    Expect(result.ViewName, EqualTo("Save"));
    var saveTagModel = result.Model as SaveTagModel;
    Expect(saveTagModel, Not.Null);
    Expect(saveTagModel.IsNew, True);
    Expect(saveTagModel.Name, EqualTo("somename"));
    Expect(saveTagModel.Slug, Null.Or.Empty);
    Expect(result.ViewData.ModelState.IsValid, False);
}

Considering what I have just said, there is an issue with the current implementation of

Create()

ITagService.Create()

Here is the test that covers that part.

[Test]
public void Create_ShowsEditorAgainOnDuplicateSlug() {
    // Arrange
    var mockService = new Mock<ITagService>();
    var controller = new TagsController(mockService.Object);
    mockService.Setup(s => s.GetBySlug("tag"))
        .Returns(new Tag("tag", "Tag"));

    // Act
    var saveTagModelArg = new SaveTagModel() {Slug = "tag", Name = "somename"};
    var result = controller.Create(saveTagModelArg) as ViewResult;

    //Assert
    Expect(result, Not.Null);
    Expect(result.ViewName, EqualTo("Save"));
    var saveTagModel = result.Model as SaveTagModel;
    Expect(saveTagModel, Not.Null);
    Expect(saveTagModel.IsNew, True);
    Expect(saveTagModel.Name, EqualTo("somename"));
    Expect(saveTagModel.Slug, EqualTo("tag"));
    Expect(result.ViewData.ModelState.IsValid, False);
}

Last but not least, here is the test that covers the success path. Out action should have called

ITagService.Save()

[Test]
public void Create_SavesTagAndRedirectsOnSuccess() {
    // Arrange
    var mockService = new Mock<ITagService>();
    var controller = new TagsController(mockService.Object);
    var saveTagModelArg = new SaveTagModel() {Slug = "tag", Name = "somename"};
    mockService.Setup(s => s.Save(It.Is<Tag>(tag => tag.Slug == "tag" && tag.Name == "somename")));

    // Act
    var result = controller.Create(saveTagModelArg) as RedirectToRouteResult;

    //Assert
    Expect(result, Not.Null);
    Expect(result.Permanent, False);
    Expect(result.RouteName, Null.Or.Empty);
    Expect(result.RouteValues["controller"], Null.Or.Empty.Or.EqualTo("Tags"));
    Expect(result.RouteValues["action"], EqualTo("Index"));
    mockService.VerifyAll();
}

Conclusion

As you can see, even though our controller is quite simple (3 methods only and simple at that), we had to write quite a few lines of unit test code to cover all the code paths. If you want to keep your unit tests to a minimum, make sure you respect the separation of concern principle. Test each of the involved components separately and reduce to a minimum the contract between them. The less they know about the other, the easier it is to change one component without your change to ripple through your whole application.

In the next few posts, I will cover testing model binding and validation as well as routes.

Don’t hesitate to hail me in the comments or on Twitter