MVC Advantages of Unit Testing Controllers

My application already has unit test for domain layer I would like to know what are the pros/cons of unit testing controller

and what test cases should one write when testing controller开发者_Go百科s.

Thanks

---

It depends.

Validation, redirection, temporary messages and so on can occur in controllers. You could argue these operations should be tested as you would your models.

On the other hand, you should be aiming for the 'Fat Model, Skinny Controller' mindset. I tend to make sure my controllers are as dumb as possible. Put a few end to end tests around the features you care about (Selenium, Cucumber etc...) and these will enforce that your controllers are correct. Say we were developing a feature to list some items. If the end to end test of this feature is fine, the controller is fine. If this breaks you'll know you've introduced a regression. In combination to this I only have tests that check the correct views are rendered and the correct response occurs - redirection, json etc... Any more testing on your controller and you have logic in the wrong place.

In ASP.NET MVC2 by Steve Sanderson he makes some excellent points about the above reasoning. I fully recommend it. The con to not having these simple controller tests is I could easily open your codebase, make a simply change and break your app. As long as the correct views/responses occur the app will still be functionally intact.

I should add that testing a service is invoked within a controller with the correct parameters is so trivial, and quick to do you may as well do this whether or not you test your controllers indirectly. I tend to favour this approach overall. So the full answer to your question is yes, test your controllers ;)

---

A 'Pro' thought:

In cases where you are passing quantifiable data or parameters from controller to a view.

In some cases, although I would think limited or rare, to test internal logic within the controller that is not covered by your supporting code tests. Although it could be argued that those pieces of code should be moved.

A 'Con' Thought:

If your tests for the controllers are not adding any additional code coverage or are duplicating test coverage, it would just overhead and add development time for no benefit.

---

Some things that may be worth testing in controller actions:

1. UI logic that gets returned in the view model (e.g. visibility, dropdown list values, etc.)
2. Redirects (e.g. logged in users going to the home page get redirected to some other page instead)
3. Validation / alerts

---

Even though you should always strive to keep business logic out of your controllers, there are often cases where construction of the view model can be so complex that it is easily worth testing.

For instance when displaying a view with several select menus which are populated by complex linq queries against your database via custom view models. That kind of logic is not business logic, so putting it in the business layer does not seem right. On the other hand it needs to be tested.

Edit: To clarify, I do not mean putting select queries in your view. That would validate the MVC pattern. What I mean is a controller that executes such queries and builds complex custom view models with the results for the view display.

---

One of the issues that I've found testing controllers is that in some instances you have to emulate the execution chain that ASP.NET MVC follows to truly test your controller.

For example, if you have code in your OnExecuting method you need to find a way to fire that method as you execute the actual action method in your controller during your unit test.