Wednesday, 26 March 2008

Test Driven Development (TDD) ... a few thoughts ...

I completed a project a few months ago using TDD (got motivated to give it a go following the architecture camp). The system is in production, and is by all accounts performing well. So yes, pleased with the results. It is difficult however for me to know whether I would have been able to acheive the same results if I had not done TDD - if I were to guess ... I think the result would have been solid either way. The system is non UI, back-end process, so all of the complexities associated with accommodating a UI system (WinForms or ASP.NET, Page/From lifecycle, blah, blah, etc) were removed.
The learning curve was certainly frustrating - I think in during steepest part of the learning curve I sent a post to the DNUG entitled 'TDD-ious?' as a result of my frustration :-/ The DNUG however was certainly a valuable resource during this time, and once it was recommended to me - and I started using Resharper and TestDriven.NET - the penny dropped. Actually, I think that doing TDD without using a tool like Resharper is equivalent to doing .NET development using Notepad (i.e. without VS) - it's really painful and just not worth it when these tools exist.
So, my approach was to implement the Dependency Injection pattern, TestDriven.NET and NUnit for testing, etc, NMock for object mocking (Rhino Mocks is probably more popular), and Resharper for everything in between. All of this makes VS feel a little top heavy, and you want to get ontop of your configuration and settings fairly quickly. I think the significant (i.e. frustrating) part of the learning curve was over by the time the work was about 50% complete (by "about 50% complete", I mean "of the total number of hours that went into the project, half of them were gone" - i.e. not "about 50% of the code had been written"), from there I had the DI pattern sorted, had come to grips with Resharper, and was able to implement a test then develop the implied code fiarly efficiently. I still felt a bit clunkly with TDD once I had closed the project, but feel competent enough with it to say that I understand how it works. I estimate that across the course of the project, 20-odd percent of my time could be attributable to 'learning TDD'. I think that this 20-odd percent would have become less and less if I had continued with TDD.
Summary - if/when you get a suitable opportunity to give TDD a go, then I recommend you go for it - you have nothing to lose and everything to gain by trying it. You may even be fortunate enough to see the light (I think I caught a glimpse of it ;-)! I think TDD is a useful approach to know how to use, whether you pursue it long-term or not. Also, the TDD following seems to be growing right now, so if you're going to be in the software development business for a while, at some stage you're almost certainly going to encounter a situation that requires an understanding of it.
Personally, I'm not using TDD right now - I have no excuses ;-)

No comments:

Post a comment

Migrating (and Open-Sourcing) an Historical Codebase: SVN-to-Git

I have a SVN repo on my local machine that I have been shoving stuff into since before I knew how to use revision control systems properly (...