How should one unit test a .NET MVC controller?
I'm looking for advice regarding effective unit testing of .NET mvc controllers.
Where I work, many such tests use moq to mock the data layer and to assert that certain data-layer methods are called. This doesn't seem useful to me, since it essentially verifies that the implementation has not changed rather than testing the API.
I've also read articles recommending things like checking that the type of view model returned is correct. I can see that providing some value, but alone it doesn't seem to merit the effort of writing many lines of mocking code (our application's data model is very large and complex).
Can anyone suggest some better approaches to controller unit testing or explain why the above approaches are valid/useful?
Thanks!
Answer
A controller unit test should test the code algorithms in your action methods, not in your data layer. This is one reason to mock those data services. The controller expects to receive certain values from repositories / services / etc, and to act differently when it receives different information from them.
You write unit tests to assert the controller behaves in very specific ways in very specific scenarios / circumstances. Your data layer is one piece of the app that provides those circumstances to the controller / action methods. Asserting that a service method was called by the controller is valuable because you can be certain that the controller gets the information from another place.
Checking the type of the viewmodel returned is valuable because, if the wrong type of viewmodel is returned, MVC will throw a runtime exception. You can prevent this from happening in production by running a unit test. If the test fails, then the view may throw an exception in production.
Unit tests can be valuable because they make refactoring much easier. You can change the implementation, and assert that the behavior is still the same by making sure all of the unit tests pass.
Answer to comment #1
If changing the implementation of a method-under-test calls for the change / removal of a lower-layer mocked method, then the unit test must also change. However, this shouldn't happen as often as you may think.
The typical red-green-refactor workflow calls for writing your unit tests before writing the methods they test. (This means for a brief amount of time, your test code won't compile, and is why many young / inexperienced developers have difficulty adopting red green refactor.)
If you write your unit tests first, you will come to a point where you know the controller needs to get information from a lower layer. How can you be certain it tries to get that information? By mocking out the lower layer method that provides the information, and asserting that the lower-layer method is invoked by the controller.
I may have misspoke when I used the term "changing implementation." When a controller's action method & corresponding unit test must be altered to change or remove a mocked method, you are really changing the behavior of the controller. Refactoring, by definition, means changing the implementation without altering the overall behavior and expected results.
Red-green-refactor is a Quality Assurance approach that helps prevent bugs & defects in code before they ever appear. Typically developers change implementation to remove bugs after they appear. So to reiterate, the cases you are worried about should not happen as often as you think.