Till last week I believed TDD (Test Driven Development) to be at best - a fashionable way to write code and at worst - an overhyped time-consuming activity which would only get in the way of delivering features. My view on TDD has drastically changed over the last 5 days - the main reason being I was forced to try it.
A few good men & women
A few of our engineers & one PM! recently held a TDD workshop for others who don't do TDD. The workshop started with hands-on where we were given a small problem of converting Arabic to Roman numerals. If you know how Roman numerals are formed you'll be able to immediately spot that certain cases like numbers from 1 to 3 follow a certain logic (keep appending I e.g. I, II, III) where as things change for other digits like 4 (IV).
The drill
The first thing we did was obviously write a test, a test for something very simple like converting a single 1 to I. This was followed by implementing the functionality and then moving on to implementing a bit more of functionality like converting 2 and 3 to II and III each step involving writing the unit test first, followed by implementing the functionality to pass the test.
The aha moment
What was striking was that we never did think of every possible case upfront. We only wrote tests for small bits which was followed by the implementation to make only those tests succeed. This is very different from what I am used to. Given a problem I usually try to keep as much of the logic as possible including exception cases in my head before starting to write code. I noticed a bunch of obvious advantages.
The good stuff
- No upfront full-fledged design, we only concentrated on small parts of the requirement
- We were forced to think of behavior / requirement in more detail, program optimization took a back seat
- With each new functionality there was a sense of achivement
- After some time, adding new functionality did not cause a concern about regressing previously implemented behavior as the unit tests kept catching unwanted changes in behavior
- We were more confident while refactoring the code as unit tests made sure behavior stayed correct
- Coding was once again fun!
Wax-on wax-off
I applied TDD to a personal project over the weekend which involves creating a Fluent Wrapper over ADO.NET. After writing over 70+ unit tests the TDD way, I can't help but wonder how I ever developed anything in the past! TDD made me think of the behavior in detail before I wrote a single line of code & I beleive this has resulted in a much better structure of my Fluent wrapper.
Oogway on TDD
To succeed with TDD, the most important thing that you need is:
An Open Mind
If you are still sticking to the old way of writing code first, I urge you to try out TDD especially in a setting where your entire team is trying this. You obviously need a:
Great Instructor
The instructor is the one who can lead you and show exactly how its done the first time, fortunately for us we had four! Another very important thing is:
You Must be Hand-On
There is no alternative to hands-on practice. If you do all of this, I promise you, you'll want to TDD everything!