Do we only test the Contoller classes in an ASP.Net MVC application?

I want to do this web application I am creating in the best possi开发者_StackOverflow中文版ble way. All the unit testing examples I have come across are for contollers only. I understand the views would be quite hard to test and perhaps the model layer would need something like DBUNit. What are your thoughts?

That's part of the point; you separate the view from the code that should be tested. But you should test any 'interesting' logic, be it in a controller or service layer, etc.

Anything in your application that isn't tested is most likely to be buggy (or get buggy after some change). On the other hand, you won't be able to test just everything.

What is usually done is to test more what's more critical and most likely to contain bugs.

Controllers are likely to contain bugs, once they usually contain some logic, and the bugs aren't too easy to be caught while just running the program. I believe pretty much anything which is not visual is more likely to contain errors, but is usually easier to test.

UI are usually manually tested even in early stages of development (just running the application and seeing what's happening is a kind of test), and they are usually hard to test automatically. But if you have a web application, and is worried if it runs well on various browsers and resolutions, I'd suggest some Selenium tests.

But usually, it's useful to ask a few questions: "How screwed would I be if there's a bug in this part [criticality]? How likely is this part to contain a bug [risk]? How hard is it to test this part [test development time]? How hard is it to keep tests up-to-date [test maintenance time]?". The answer to these questions may be a good starting point on deciding what to test or not.

You can test your Routes.

You'll get different opinions on whether views should be tested or not. Many people will argue that since UI tends to change rather frequently, that unit tests on views are brittle and cause more harm than good. Others will argue that everything must be unit tested, views included.

As far as only testing the controllers, that's probably a bad idea. The most important part of your application, the domain, should be where most of your business logic resides and thus must be tested. Things like data access, services, etc. should also be tested (and presumably, don't reside in your controllers).

In short, no, controllers aren't the only thing that need unit tests. However, you can probably get away with not unit testing your views.

You should test everything that you can test. Apart from Views (aspx and ascx files) that pretty much includes all the rest of your code.

These days, the "M" in MVC is usually understood as a ViewModel, which is a dumb data structure with limited (and self-contained) behavior. Part of the Controller's responsibility is to map back and forth from the underlying Domain Model to ViewModels.

You can use ordinary unit testing frameworks to unit test your Domain Model as well.

Test-Driven Development gives you the best assurance that you get as high a Test Coverage as possible.