Even though Microsoft continues to tout testability as a reason to adopt ASP.NET MVC over WebForms, it really isn’t a good reason.  It is interesting that this is the first product I’ve seen where there is a first-class tutorial explaining how to test code that is coupled to some part of the framework.  Interesting, I’m unable to find a Microsoft tutorial or MSDN Library article talking about unit testing with WebForms, WCF, ASMX, Workflow Foundation, BizTalk, WinForms, WPF, etc.  Now, I’m sure there is some material, and if there is “official” documentation regarding this, I would love to know so I can help bring visibility to it.

I am a big proponent of Test-driven development, and I even teach it in the Agile Boot Camp classes from Headspring.  If you work for me, you must do TDD.  No exceptions.  You might find it odd that I say that testability is not a reason to use ASP.NET MVC.

There is ONE reason I use ASP.NET MVC.  There is ONE reason all of my employees use ASP.NET MVC.  There is ONE reason it is now part of the standard Headspring Architecture for all client web application.  What is this one reason, you ask?

It works the way I want to work, and it doesn’t get in my way.

I realize this reason is very subjective.  I’m ok with that.  My mission is not to convince the whole world to use this framework.  In fact, Headspring is responsible for a handful of open–source projects, but it really isn’t important to us that anyone else uses them.  They are useful to us.  ASP.NET MVC is useful to us.

It works the way I want to work

• I want work work among .Net interfaces.  When I want to extend something, I like being able to create an alternate implementation for the interface.  This is the way object-oriented programming works.  The simple fundamentals hold fast. 
• I want to work with small classes.  In WebForms, it was very difficult to keep each WebForm small.  With ASP.NET MVC, it is easy to accomplish.  Each controller action has 3 or 4 lines of code coordinating work with other dependencies.  Route configurations are easily pulled into supporting classes and wired in as an HttpModule.  Views are easily partitioned using partials.  Cross-cutting functionality is easily segmented as ActionFilters.  Rich parameter types are available through custom model binding classes that convert Querystring and Form values into domain objects.  The framework is spread out.  Simple classes everywhere.  Rendering is firmly separated from handling user input.  Business rule validation is easily kept out of the controllers and views in lower layers of the application.  In short, I never find myself trying to find just the right place to wedge in a couple of lines of code.  There are plenty of abstractions.  Every bit of code has a place.
• I want to distribute work among several members of a team.  It is almost impossible to have more than one person working on a single WebForm.  It is rather easy, however, to have several developers working on the same controller, each have one action.

It doesn’t get in my way

• It doesn’t saddle me with static properties and other object oriented dead ends.  Every abstraction can be substituted when the default is unsuitable. 

Back to testability

Because ASP.NET MVC is designed well, it is testable.  It was not designed _to be testable_.  It was designed to allow corresponding code to be loosely coupled.  It was designed using solid object-oriented concepts.  Any code designed in this fashion is testable.  Testability is a side effect of good design, not the design itself.

Although I love TDD, please don’t adopt ASP.NET MVC because someone has told you that it will enable test-driven development.  You can do test-driven development without ASP.NET MVC.  Adopt ASP.NET MVC based on other factors.  Adopt it if it works the way you do.  Adopt it if it doesn’t get in your way as much as alternatives.  Adopt it if it helps you move faster.  Adopt it for reasons you value. 

If you are productive with WebForms; if you don’t have any pain with your current approach, please don’t switch.