views:

39

answers:

1

I was just wondering how others are going about testing controller actions in asp.net mvc? Most of my dependencies are injected in to my controllers so there is a not a huge amount of logic in the action methods but there may be some conditional logic for example which I think is unavoidable.

In the past I have written tests for these action methods, mocked the dependencies and tested the results. I have found this is very brittle and a real PITA to maintain. Having 'Expect' and 'Stub' methods everywhere breaks very easily but I don't see any other way of testing controller actions.

I actually think it might be easier to test some of these manually! Anyone have any suggestions? Perhaps I am missing something here?

Thanks

Imran

+1  A: 

i don't think i've writtin a single test for a controller because all of my logic is elsewhere. Like you say the controllers have a minimum amount of code in them and any logic in them is so simple that it really doesn't bear a whole test strategy.

i prefer to give my models a whole lot of tests as well as any supporting code like DTL's and data layers etc.

i think i've seen some people mock up their copntollers, pass in the expected models and look at the resultant output but i'm not sure how much that gives you.

i think if i were to test a controller i'd only really test the post actions to ensure that what is being given to my controller is what i'm getting in my model as well as testing (security). But then I have security in a number of places of varying levels.

but all that is integration testing more than functional. functional i do elsewhere like i said earlier.

then again, if it's worth writing then it's worth testing huh? I guess you need to decide what and where the breakable bits are and how you want them tested.

griegs
I agree, I have seen samples and blogs talking about TDD with controllers and have always wondered how much you actually gain from it. I'm all for TDD but it somehow feels wrong writing tests for controllers that hand most work to other components. I agree that these would really be integration tests.The main reason I was thinking about this was to ease regression testing. If I make a change to the site, I have my usual unit tests but its also possible that some view or controller may have broken in the process. At the moment it looks like I would be going through testing this manually.
Imran
Well there's always some logic in controllers, or why have them? I'd test the logic that you wrote that *is* there. For example, that it hands off the right work to the right components and stop right there.
Haacked
True however, it is this sort of interaction based testing that I am finding to be very brittle. I think I might limit controller testing to things like exception handling and argument validation as a compromise. Or I guess just testing the correct component was called is enough rather than setting specific expectations on arguments that they are called with etc.
Imran