When they sell you improved testability in ASP.NET MVC, they usually cite the foundational ScottGu's post and write a cute unit test for a controller. With all these beautifully hand-crafted mock authentication services and built-in Http***Wrappers.
Wow!
While it's certainly a big step in the right direction, compared to WebForms' code-behind, let's face the truth: it's far from ideal. While testing Binders and Action filters is doable, it requires ridiculous amount of setting up, guessing what to stub and what to return, etc. With Views, it's much worse (and don't tell me you shouldn't have code in your Views, because you have lots). So, after working with complex MVC sites for the past year (yes, I know I'm slow to adapt new technologies), I realized that, despite the celebrated testability of MVC, I still need Ivonna to, like, really test this stuff.
With Ivonna, you get the benefit of a "live" HttpContext (and other Http*** stuff), and at the same time, the possibility to investigate the underlying objects and even intervene here and there. For example, issue a POST request with a concrete URL and post data, and investigate the list of input variables for the action method, effectively testing your binder in a real life situation. While you can do all that with the 2.* version, it's been built around WebForms, and working with other frameworks requires quite a lot of preparation. This is why I decided to take her to Level Three.
The new, improved Ivonna will have its core classes decoupled from the WebForms universe, while staying kinda backwards compatible (more on that in another post). At the same time, I plan to add a lot of usefulness, simplifying testing various pieces of the ASP.NET MVC framework. In addition, I really want to try FubuMVC, so expect some FubuMVC extensions as well (available as a separate binary, and most certainly Open Sourced).
So, I invite you, my dearest audience, to share your wildest ideas about testing the MVC stuff you code: what's hot, what's not. If you're completely satisfied with the existing possibilities, please say so as well. Here are some things I do plan, and I'd be grateful for your comments:
- Getting a list of invoked action methods (parent and child), together with input parameters and results.
- Investigating the
IView
instance -- often I want to know not just the model, but also the model metadata and other stuff passed in. - Whenever I write
Html.RenderAction
, or Html.RenderPartial
, inside my View, I want to test the output (as well as the output of Html.SomeOtherStuff
). - On the other hand, sometimes it's easier to just submit the model object, bypassing the binder. Ensures consistency, too: what if your model has changed but the field names in your tests remain the same?
- Really need to test the routes: ensure that a particular URL corresponds to a particular route.
- Don't know what else. I know I've promised 58 of these, can you help me with the remaining 53? Please reply in the comments.