I found my team starting a new project this week. Since this new project does not have any legacy code, we wanted to set the thing up with all the new process and ideas that we've been working on for the last few weeks. Specifically, we wanted to implement Model View Presenter and Unit Testing. After getting the core projects set up and adding all of the appropriate references to nUnit, the project being tested, etc., I set of to start coding my first screen. 95% of the way through the screen layout, I realized that I had completely forgotten to implement any of the MVP or Unit Testing that I knew was supposed to be done. Oops - so I go back and and create the appropriate presenter shell, view interface shell, and start the process of Test Driven Development as if I hadn't done any of the view implementation yet. As I got into the process of designing the presenter via my unit tests and started working with a mock view object, I found that I was highly confident in what the end-user's view could be. I was certain that the screen would work as expected and I knew that the view would meet all of the requirements.
It's amazing to me how quickly I can see the benefits of not only the Model View Presenter pattern, but also unit testing. I have previously blogged about one benefit of MVP - being able to understand what the view is supposed to do and how it will work, without actually seeing the view. Now, with unit testing in the process, I'm finding that not only can I see what the view is supposed to do without actually seeing the view, I can also guarantee that the functionality of the application will be correct. On top of that - I have gained this confidence without running the application once; I never opened the debugger, and never set any break points; I never had to wait for the application to build, never had to wait for the debugger to attach, and never had to run through any complicated process of setting up any sort of state within the application to verify the functionality.
Every moment that I can spend outside of the debugger is a moment that I am being productive by writing new code or correcting code that I already know is broken. How do I know it's broken? unit tests. How do I manage to stay out of the debugger as long as possible? unit tests, again. If I cover 90% + of the code that I'm writing with unit tests, I can spend 90% less time running the application and debugging to find problems. When you balance out the time savings from debugging with the time spent writing the unit tests, I'm certain that you will see the net result of time being saved - not only now, but also in the future the when the application's requirements change. With my current one screen in this particular project, I am estimating a 2 to 3 hour savings immediately. I'm not actually sure about how much time will be saved in the future because this process is new to me and my team but I can imagine as time progresses and requirements change, the savings seen now will only increase.
A small screen, a presenter, a mock view, and a handful of unit tests: 2 hours... confidence that the code will work without actually running the application: priceless... I'm really starting to like this TDD stuff.