I am writing more personal stuff today as I have been busy finishing a project the past few days and had little contact with the developer community :)
On my recently completed project I took my first real-world stab at test-driven development using NUnit. The project required a moderately complex business object that seemed to be a perfect candidate to build from a test first perspective. The business object 1) had a lot of methods, properties, and indexers that exposed/manipulated a lot of internal objects and collections and 2) performed several complex calculations on the internal objects and collections. The business object was also primarily memory resident as opposed to using a data store, which meant I didn't have the issue of building unit tests that required database rollbacks and set-up and tear-downs. Indeed it was a perfect candidate for my initial test first development exercise. ( Don't confuse this as being my first time writing unit tests. I started using NUnit over a month ago and have written several hundred unit tests to get comfortable with it. )
No real learnings here other than the obvious that you would expect for trying something new for the first time. It was slower to develop the business object as the process was foreign to me. I found myself constantly re-writing methods as I would first code enough to pass the test and then had to go back and put real-world logic to accommodate real needs. Refactoring is unbelievably important as you fight to keep from looking ahead and isloating common code from the very beginning.
On a positive note, I had a bit more fun developing the business object as I was trying something new. I not only felt a sense of accomplishment when the test passed, but also knew what needed to be worked on when tests failed. It was as if Nunit was less about testing and more of a TODO list. My TODO list was to get those little red dots green :) It started to be somewhat of a game.
The beauty is that after everything was said and done I had not only accomplished the business object but also had a nice suite of tests to tell me the general health of the object. Normally I would build a lot of the unit tests at the end, which is like first eating your dessert and then eating your peas and carrots. In Test-Driven Development, I get to sample from each food making the process just a little bit nicer.
I have already identified a few places on a new project where I can once again use the test first approach to development. For right now I will continue to just focus on more manageable business objects to practice TDD as opposed to adopting it for a complete project. For smaller-scale projects, I can't justify the extra time in delivering the project and the additional cost to write suites of unit tests. Gotta stay competitive!