Test driven development (TDD) has always been somewhat of a holy grail for me in so much as I’ve always wanted to get to grips with it but could never find a way in. I’d often thought that getting started would be pretty tricky and since the projects I work on are already well established they would not best suit TDD.
After Craig Nicol’s TDD session at DDD Scotland this apprehension all changed because his session showed TDD from the very beginning and in fact I even found myself trying out TDD on a simple roman numerals project that evening. The concepts of TDD made a lot of sense and two things occurred to me after following them on a project.
The first thing that came out of trying TDD was that I no longer feared the refactor; something I often dread. Refactoring without tests had always required an awful lot of forethought and care, of course followed by several lengthy manual checks to confirm that I hadn’t broken something. With tests in place I knew that I could make all sorts of changes and click a button to see what I had broken, if anything! The second thing was a realisation that the code I ended up with was much less complex and much more concise than what I had tried to build in my mind.
With this new found knowledge under my belt I have decided to attempt to complete Craig Murphy’s programming challenge using test first TDD and posting about it on my blog. The programming challenge denotes that for a given inputted uppercase letter, a diamond should be outputted with A at the top and bottom and the inputted character at the widest point.
Since getting input from the keyboard and writing the diamond to the console are pretty straightforward I will only be testing the validation of the input and the generation of the diamond in my posts. In an effort to keep the posts pretty short and easy to grok I will split my progress over several steps highlighting each of the milestones I meet along the way.
I will be following the 3 laws of TDD as laid out by Uncle Bob Martin during his Software Craftsmanship keynote at Oredev 2008:-
- You are not allowed to write any production code until you have a failing unit test.
- You are not allowed to write more of a unit test than is sufficient to fail, and not compiling is failing.
- You are not allowed to write more production code than is sufficient to pass the currently failing test.
Armed with these laws I will, over the coming days, document the steps I have taken along with the demo code which will be available for download. I will be using C# inside Visual Studio 2008 Professional with it’s inbuilt testing framework.
Setting up the project
Before I get started on putting this together I will need a test solution and project to get me going. This can be created in Visual Studio 2008 from the File…New…Project menu option, selecting Test Project from the Test section of the project type tree and clicking Ok.
This automatically creates a test class with a bunch of initialization code and one attribute decorated test method we can use as a template for all the future tests we create manually.
Other TDD for Beginners Posts