Building Highly Testable Web Applications With ASP.Net MVC

Web applications are notorious when it comes to testability. The problem is further compounded when applications have a complex user interface. Recently we did an architecture consulting for one of our clients in the financial industry for a web based application which is part of their core product offering. The product is an enterprise solution which supports multiple client configurations. The application is built on classic ASP and COM relying on the main database of the product for storage apart from a centralized file storage system.
One of the key challenges faced by the application was testability. With code and markup being tightly coupled, what some ASP.Net developers derisively call as spaghetti code, it was close to impossible to write functional unit test cases for the application. The most likely solution was migration of the application to ASP.Net with clear separation of code from markup. However past experience told us that this works well only if the pages are fairly simple and complex pages often resulted in bloated code behind files which are hard to test and maintain. This lead us to consider ASP.Net MVC as a suitable solution approach.
In the world of web applications adoption of MVC pattern opens up possibilities like never before. It is common practice to have minimal code in the code behind and move the operation logic in its entirety to controllers with the ability to support multiple views. This enables clear separation of view from the presentation logic and thereby creating opportunities for testing the application which hitherto didn’t exist. Typically a test double is hooked up with the controllers and one could proceed with testing well before the look and feel of the user interface gets finalized.
The folks at Microsoft foresaw this and introduced the ASP.Net MVC framework as an alternative approach to the traditional web forms based development model. ASP.Net MVC paves way for building applications which follow test driven development (TDD). Controllers could be unit tested outside the ASP.Net process itself and any unit testing framework could be leveraged for this purpose.
There are other benefits as well such as ASP.Net MVC comes with a powerful URL routing mechanism. No longer are requests made to specific web pages with an extension. For example, the URL MyServer.com/Orders/Status/1234 would replace MyServer.com/Orders/ Status.aspx?id =1234. Note the difference: ASP.Net MVC URLs follows a more RESTful style compared to the old web forms model.
Few points that need to be kept in mind before making key decisions:
1) ASP.Net MVC ushers in a radical change in the underlying framework. Pages no longer receive requests; instead requests are routed to controller classes which manage the views. It is quite possible to support other higher level frameworks on top of MVC, for instance building a composite user interface with Composite Web application block with an MVC approach is possible.
2) ASP.Net MVC as a framework addresses building user interfaces in a fundamentally different way. However when it comes to strategies for authentication, session management, use of providers, authorization, localization, caching etc there are no changes. An interesting implication is parts of an application rebuilt with ASP.Net MVC can coexist with rest of the application still using the web form post back model making a strong case for migration.
3) ASP.Net MVC introduces more elements in the projects than one would normally have. It is typical for a complex web page to be broken into multiple views and controllers. In a sense, few tightly coupled larger components are broken up into several loosely coupled parts. Sometimes this is viewed as a disadvantage.
4) One does really need to think in terms of MVC to realize the benefits, and better design skills can make a telling difference. ASP.Net MVC applications are typically high on design.

Since the key issues of our client revolved around testability and a maintainable codebase, ASP.Net MVC seemed to be a natural fit. However there were some concerns around ASP.Net MVC being a brand new framework in its beta version (a release candidate is available now). However such fears were unfounded for the following reasons:
1) ASP.Net MVC though it was a beta version came with an explicit go live license from Microsoft. Microsoft had experimented with several preview editions for almost a year, before deciding the bits for the beta edition. A "go live" license ensured backward compatibility in future versions.
2) Building web applications on MVC is an established norm, though it is new to ASP.Net. Frameworks like Ruby on Rails rely heavily on the MVC pattern. Even before ASP.Net MVC , third party solutions were available for building ASP.Net applications using MVC pattern. More notable among them is Monorail framework of Castle project. ASP.Net MVC works well with these third party solutions. For example ASP.Net MVC optionally lets users plug in MonoRail’s view engine.

Apart from suggesting the ASP.Net MVC approach, recommendations were made around strategies for session management, caching, storage, load balancing, use of third party controls & themes. All considerations applicable to ASP.Net applications hold good for applications built on ASP.Net MVC.
As with any new framework one can expect some churn, however the most recent cut of ASP.Net MVC is quite stable and without doubt a whole new way for building great web applications.