Tuesday, 9 December 2008
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.
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.
Subscribe to: Post Comments (Atom)
Apple started a user experience trend many iOSes ago when it accepted Settings changes and did not ask for confirmation. Once the chang...
Recently I was asked to disable the submit event being triggered when the enter key is hit in a textbox input. This is for an ASP.NET MVC ap...
Five years ago, everybody seemed to want to have the word "architect" in their title. Firstly, they all needed a title and having ...
Photo by aeter used under the flickr creative commons license I was recently asked by one of my colleagues at ThoughtWorks, who my female r...
Hi there, I'm an organizer for the GGD in Milan, I added you on Twitter just to keep in contact with other organizers around the world! :)
Post a Comment