I hope this question gives some interesting answers because it’s one that’s bugged me for a while.
Is there any real value in unit testing a controller in ASP.NET MVC?
What I mean by that is, most of the time, (and I’m no genius), my controller methods are, even at their most complex something like this:
public ActionResult Create(MyModel model)
{
// start error list
var errors = new List<string>();
// check model state based on data annotations
if(ModelState.IsValid)
{
// call a service method
if(this._myService.CreateNew(model, Request.UserHostAddress, ref errors))
{
// all is well, data is saved,
// so tell the user they are brilliant
return View("_Success");
}
}
// add errors to model state
errors.ForEach(e => ModelState.AddModelError("", e));
// return view
return View(model);
}
Most of the heavy-lifting is done by either the MVC pipeline or my service library.
So maybe questions to ask might be:
- what would be the value of unit testing this method?
- would it not break on
Request.UserHostAddressandModelStatewith a NullReferenceException? Should I try to mock these? - if I refractor this method into a re-useable “helper” (which I probably should, considering how many times I do it!), would testing that even be worthwhile when all I’m really testing is mostly the “pipeline” which, presumably, has been tested to within an inch of it’s life by Microsoft?
I think my point really is, doing the following seems utterly pointless and wrong
[TestMethod]
public void Test_Home_Index()
{
var controller = new HomeController();
var expected = "Index";
var actual = ((ViewResult)controller.Index()).ViewName;
Assert.AreEqual(expected, actual);
}
Obviously I’m being obtuse with this exaggeratedly pointless example, but does anybody have any wisdom to add here?
Looking forward to it…
Thanks.
1
Even for something so simple, a unit test will serve multiple purposes
- Confidence, what was written conforms to expected output. It may seem trivial to verify that it returns the correct view, but the result is objective evidence that the requirement was met
- Regression testing. Should the Create method need to change, you still have a unit test for the expected output. Yes, the output could change along and that results in a brittle test but it still is a check against un-managed change control
For that particular action I’d test for the following
- What happens if _myService is null?
- What happens if _myService.Create throws an Exception, does it throw specific ones to handle?
- Does a successful _myService.Create return the _Success view?
- Are errors propagated up to ModelState?
You pointed out checking Request and Model for NullReferenceException and I think the ModelState.IsValid will take care of handling NullReference for Model.
Mocking out the Request allows you to guard against a Null Request which is generally impossible in production I think, but can happen in a Unit Test. In an Integration Test it would allow you to provide different UserHostAddress values (A request is still user input as far as the control is concerned and should be tested accordingly)
2
My controllers are very small as well. Most of the “logic” in controllers is handled using filter attributes (built-in and hand-written). So my controller usually only has a handful of jobs:
- Create models from HTTP query strings, form values, etc.
- Perform some basic validation
- Call into my data or business layer
- Generate a
ActionResult
Most of the model binding is done automatically by ASP.NET MVC. DataAnnotations handle most of the validation for me, too.
Even with so little to test, I still typically write them. Basically, I test that my repositories are called and that the correct ActionResult type is returned. I have a convenience method for ViewResult for making sure the right view path is returned and the view model looks the way I expect it to. I have another for checking the right controller/action is set for RedirectToActionResult. I have other tests for JsonResult, etc. etc.
An unfortunate result of sub-classing the Controller class is that it provides a lot of convenience methods that use the HttpContext internally. This makes it hard to unit test the controller. For this reason, I typically put HttpContext-dependent calls behind an interface and pass that interface to the controller’s constructor (I use Ninject web extension to create my controllers for me). This interface is usually where I stick helper properties for accessing session, configuration settings, the IPrinciple and URL helpers.
This takes a lot of due diligence, but I think it is worth it.
5
Obviously some controllers are much more complex than that but based purely on your example:
What happens if myService throws an exception?
As a side note.
Also, I’d question the wisdom of passing a list by reference (it’s unnecessary since c# passes by reference anyway but even if it wasn’t) – passing an errorAction action (Action) that the service can then use to pump error messages to which could then be handled however you want (maybe you want to add it to the list, maybe you want to add a model error, maybe you want to log it).
In your example:
instead of ref errors, do (string s) => ModelState.AddModelError(“”, s) for example.
10