I've been searching on how to do Unit testing and find that it is quite easy, but, what I want to know is, In a asp.net mvc application, what should be REALLY important to test and which methods you guys use? I just can't find a clear answer on about WHAT TO REALLY TEST when programming unit tests. I just don't want to make unnecessary tests and lose development time doing overkill tests.
+1
A:
I actually don't think anything needs to be tested in MVC. I think all your business logic, rules etc need testing but the Views and Controllers?
The only real reason I can see to test a Controller is for integration testing. If all your business logic is correct then that should be a simple test always returning true.
Controllers should really only get data from the view and pass data to it so....
As for views, what sort of testing can be done there other than to open the view and see what it does?
When I write my projects there is next to no code in the controller and I put all the grunt in my business engine which I have extensive tests for.
griegs
2010-04-06 23:22:24
You don't want to unit test "if a user isn't logged in they shouldn't go to a SECURE controller?" or "if a user doesn't fill in a required field they don't proceed to the next screen" in a wizard?. Ever hear of Selenium for testing views in a browser?
jfar
2010-04-06 23:33:22
Actually if you are going to a secure controller then that should be calling a business layer object somewhere and that, i think, should do some basic logged in tests. That can then be tested. if you want to test to see if the controller executes if not logged in then yeah sure write a test. personally i prefer not to rely on controllers to handle that level of security.
griegs
2010-04-06 23:36:19
Something in your BLL still has to say "no, this isn't allowed" and then MVC still has to redirect to another screen. Even if your controller is as simple as if( bll.IsAuth() ) { //do redirect } don't you want to be sure the redirect happens? "prefer not to rely on controllers to handle that level of security" Your relying on some piece of the HTTP pipeline someplace for security and thats usually exposed via controllers.
jfar
2010-04-06 23:43:16
You make some valuable points there jfar. i think where i'm coming from is that when i start a project the security model is generally the first thing i do and it's mostly copy paste from existing projects. so i kinda know the security works and that [authorise] will do what it's supposed to. a quick check on the view can confirm it. so i guess having at least one test on a secure controller might not be that bad an idea
griegs
2010-04-06 23:49:42
+1 The MVC layer should have almost nothing worth testing in it. Core logic goes in the model which should be well tested. I agree with jfar that you might want to test security critical code, but any security done in the MVC layer should just be a "double check" of the BLL.
Ryan
2010-04-07 00:43:14
Thanks Ryan. But security should be tested and having at least a test that tests it should be there and might even come under the title of Integration testing like I mentioned in my answer.
griegs
2010-04-07 00:46:39
Views absolutely SHOULD be tested! Add this to a View: Html.TextBoxFor(x=>x.ThisPropertyDoesntExist)... it will compile! It won't even warn. Selenium, Watin, use something but don't assume Views shouldn't be tested.
Dave Swersky
2010-04-07 01:16:34
I think we're getting mixed up with testing in general, and unit testing specifically.
UpTheCreek
2010-04-07 06:09:44
@Dave It's possible to write an integration test that attempts to compile all of your views which would catch that error. Selenium is overkill unless you're testing behavior. I drive all my view behavior (buttons, output formatting, etc) off of conventions. If the conventions are tested, your view is tested as far as I'm concerned.
Ryan
2010-04-07 15:25:45
A:
Unit testing is good for testing of services/models. But when you need in testing of application functionality the better choice will be functional tests (i.e. Selenium)
zerkms
2010-04-06 23:32:39
+5
A:
You should unit test as much as possible of your application.
For every line of code you write, you need to verify that it works. If you don't unit test it, you need to test it in some other fashion. Even starting up the site and clicking around is a sort of testing.
When you compare unit testing with other sorts of testing (including running the site and manually using it), unit tests tend to give the best return of investment because they are relatively easy to write and maintain, and can give you rapid feedback on whether you just introduced a regression bug or not.
I'm not saying that there's no overhead in writing unit tests - there is, but there's overhead in any sort of testing, and a big overhead in not testing at all (because regression bugs slip through quite easily).
It's still good practice to supplement unit tests with other types of tests, but a good unit test suite offers an excellent regression test suite.
Mark Seemann
2010-04-07 03:24:30
+1 "If the code deserves to be written, it deserves to have tests." (The Way Of Testivus)
Yann Trevin
2010-04-07 09:16:05
+3
A:
Ron Jeffries says "Test everything that could possibly break."
Someone else - I think it was Kent Beck, but I can't find a reference - says, "Only test the code you want to work."
Either of these is a pretty good strategy.
Carl Manaster
2010-04-07 04:46:30