Doron's .NET Space

ASP.NET MVC Framework? Don't Mind If I Do

I'm spending the weekend at work (don't ask), so I had some time to read some articles and view some webcasts I left behind. I finally got to watching the entire lecture Scott Guthrie gave at the ALT.NET conference about the ASP.NET framework. You can check out the video here, and read about in Scott's blog, here.

My initial impression of this was: Wow. This is so awesome. Finally ASP.NET is becoming a testable, maintainable platform. As I've mentioned, my team has recently entered TDD. The only thing that is incredibly hard to test in our architecture are the WebForms pages. There are ways to overcome this, but none of them is natural because of one simple truth: WebForms has tight coupling between logic (.cs file) and view (.aspx file). Furthermore, the suggested way to test ASP.NET pages in VSTS requires using a web-server, and loading the entire ASP.NET, well, stuff. And that is all kinds of slow.

Using the MVC framework we will have testable controllers (which are just classes with some logic in them, which you can test like any other class), and views that are really responsible only for display. Also, everything will have an interface. Dear IHttpContext, how I've longed for you since the dawn of time.

It definitely seems like this will be the way to develop applications over ASP.NET (although standard WebForms will continue to be supported and developed, says Guthrie). My main concern is the transition between the two platforms. For the project, and for the team. For the project, we currently have the standard ASP.NET web site (which sucks. We now wish we had chosen Web Application Project. We sure do miss that .csproj file), and a whole bunch of .aspx files. System.Web.MVC will work in an entirely different way: Controllers will have several views, no post-back, no view-state. Moving will probably be incredibly hard.

For the team this will also be difficult. We are so accustomed to working with the control life-cycle model, using and writing server-controls that handle their state, that this will probably take us a long way back in terms of productivity, initially. In fact, none of us developed web applications in anything other than ASP.NET, so the "step back" that the MVC framework takes towards working more closely with HTML might be problematic.

But problems aside, I really can't wait to get my hands on this framework and start playing with it. It feels very right, and seems to me like a step in the right direction by Microsoft.

Computer Trouble

Another hilarious comic by xkcd.

Implementing TDD: Advice from the Battlefield

Changes are hard. I recently mentioned that. But changes are also necessary. I will now share with you some advice I have about the subject of implementing a change - starting to use unit-tests and TDD at your workplace.

1. You should have some experience with unit-tests yourself before moving your entire team to TDD. Is the architecture your team using even testable? Can you understand the usage of a mocking framework? If you don't come with the knowledge to the team, you're in a world of hurt. Remember, this is a difficult change which can't be rushed. You should be prepared.
   
   
2. It won't happen by itself. The first thing you have to understand is that writing unit-tests is something that most developers will prefer to not do, at first. I expected that I will just tell the team to start writing unit-tests for all their methods and they will. I figured they might struggle, but that things will work out. That was, of course, very silly of me. Writing unit-tests is hard at the beginning, and it takes time to see the benefit of this (not too long, though). A developer won't do a difficult task when he can't understand the benefit from it. It's a simple as that. 
   
   
3. It will be much easier for the team to start writing tests if they have whatever supporting frameworks and base classes they need ready to work.
   
   
4. Examples are important. You should be able to present actual tests you wrote using the above mentioned frameworks, to production code. This is crucial. At first I tried showing the team an example of writing and testing a Stack<T> class. That was not very effective, as it isn't the type of code we usually write (DB access and business logic). The team should have a real-world example to use as a reference.
   
   
5. Make sure the importance of writing tests is understood. Prioritize writing tests over writing new code. Make them understand that a piece of code is not complete until it is fully covered by working tests.
   
   
6. It might be a good idea to set a week aside for just working on the first few methods and their tests. Dedicate most of your time in this week to provide assistance and to perform code-reviews on the code and its tests.
   
   
7. Don't forget to setup daily builds which will run the tests periodically.
   
   
8. Don't be discouraged and never give up, even if the team shows resistance to the move. Even if they can't see the point now, I promise that before long they will be telling how many bugs they were able to prevent, and how great it is that you don't have to be scared of changing old code. They will feel good and proud to see the green bars of passing tests.
   
   
9. Expect the chaos. It is a part of every change.
   

My team has yet to complete the move. We are still learning the ins and outs of the method. Still, I hope the hard part is behind us, since as of now almost everyone has written working and reviewed tests for all their code in the current release. If you're interested, we're using VSTS for writing the tests, Rhino Mocks for mocking, and TFS for integration.

Good luck.