Learning about Testing ASP.NET MVC

Working on my first commercial implementation of ASP.NET MVC Beta has been rewarding and frustrating to almost even degrees. Learning to test the MVC framework after hearing the promises of Microsoft and the choir has proven that it is still young and the road is long. It feels like being back in .NET 1.1 land again but as an eternal optimist, I see that as meaning that ASP.NET MVC has a promising future. As promising as C#, which had humble beginnings.

Abstracting the business value and corresponding actions in to the C part of MVC has meant that the code behind an ASP.NET Page is reduced to nothing more than specifying the type of model that the strongly typed View uses. That solves an enormous amount of problems that came out of the pre-ASP.NET-MVC world. In particular the classic-ASP-like tendency to put all logic straight in to the events in the code-behind with little to no abstraction. Since you can not instantiate a Page object outside of the ASP.NET framework, it was impossible to unit test the controlling logic in the code-behind. When I have walked on to a project and seen the 3000 lines of code nested in page events, I knew it was almost impossible to safely refactor let alone extend the functionality. All changes in that case had to be additive and in no way morph logic so that nothing legacy would be broken.

The ability to test Controllers has pushed that code out in to a testable .NET class that can be instantiated independently of the framework and then easily tested. That's brilliant if you weren't already doing that but most of us were. I do commend Microsoft on forcing some sort of design on to us but as usual it's all mechanism and no policy. It's another easy way to say "put it all here" but also test it.

What I want to see out of future ASP.NET MVC releases is the ability to test Views with simple xpath searches and annotation validators on Models that feed through to the View. Yes, it's not there now but it will be soon as we can see in MVC Futures. This is not a case of Microsoft missing the point at all. They just have to release something and then they will add to it. They have shown their responsiveness to community feedback. If only they wouldn't refer us to stackoverflow.com.

From the conversations we have had with Microsoft, they have started by saying that it's only the Controller that needs testing and that Views should be tested by a UI testing tool like Selenium and that models have accessors only so don't worry about them. There is then the realisation that testing your View as an abstract concept is not a bad one since it is faster and most efficient than using the UI tools with their overhead (even headless). It certainly will let us test state more efficiently. As for models, validation is so important that the lack of access to annotation validators has resulted in an excess of JavaScript (beit jquery) in our application and I'm not convinced that is a good thing yet. Maybe that's my C# bias kicking in.

I for one am looking forward to the MVC futures becoming MVC present. Until then, all the positive parts of this new framework like the ease of integration of the Model, View and Controller make up for all the things I still want. It saves me the time I used to spend on implementing MVC in the old world.

This leaves me extremely optimistic about the future of .NET web development. Until then, let's do our best to avoid the fat Controller.