Do you get Test Driven Development (TDD)?
I would like to think I am a TDD practitioner but, honestly, I’m not. I understand TDD, I know the theory inside out and back to front, I can write automated tests in my sleep. I can perform cylcomatic complexity analyses of code and reduce my testing efforts through combinatorics, but none of that matters, ’cause TDD ain’t about testing.
Chris and I met with Jonathan Rasmusson from Thoughtworks the other day to discus a presentation that he will be delivering to our developers next week about TDD. During that short session I finally realised why people have trouble using TDD. They think it’s a testing technique.
Signs you don’t get TDD
The first step to recovery of most problems, is to accept you have a problem, and only then you can do something about it. A lot of people think that they get TDD when actually they don’t.
If you answer yes to any of these questions, you probably don’t really get TDD.
- Do you think TDD (and other Agile techniques), are just a new name for something you have been doing for years anyway?
- Do you develop your unit tests after you have written your code?
- When you estimate a development task, do you include separate time for design, construction and unit testing?
- Are unit tests something you will do only if you have time, and they are the first thing to be cut when the schedule gets tight?
- Do you see little value for writing new tests for existing code, even if it is under active development?
- Do you think that unit tests are all about meeting a requirement that has been forced on you, and they add little true value?
- Do you feel, achieving 100% code coverage with tests is a completely unrealistic goal?
- Do you think that test code does not need to be of the same standard as the code of the application itself?
- Do you see no value in writing a new test for each defect that is found in the code?
- Do you think TDD is a testing activity, as opposed to a design or coding activity?
Ok, so I don’t get TDD, what am I missing?
I think the key to truly understanding TDD is to stop thinking of it as Test Driven Development, and instead think of it as Test Driven Design. The practice of writing failing tests first is the nut to crack. Once you buy into that concept, and get to the point that you are no longer comfortable writing any code without tests, is when you truly get TDD.
Let me use an example. Say we are developing an application to book passengers on a flight from Sydney to Brisbane. The first thing that we would be able to want to do is to create a passenger to allocate to our booking. So we would write a test that creates a passenger and confirms that it is not null.
[Test]
public void CreatePassenger()
{
Passenger Booking = new Passenger("Bruce McLeod");
Assert.IsNotNull(Booking, "The Passenger created for new booking is null.");
}
Just by writing the test we are already making design decisions about the eventual implementation of our passenger class. We have decided on the name of the class, if the class is static or not and we have decided how the object’s constructor will be called. We are still yet to write a single line of actual code, and we are already making design decisions around how our code will be implemented.
This is what TDD is all about, making design decisions before we implement the code, and then validating the code implements our decisions by running the tests.
I have just scratched the surface of TDD, and there are far better people than me to teach you how to do it. To start with I would highly recommend the original Junit article, JUnit Test Infected: Programmers Love Writing Tests, a TDD webcast given by Jim Newkirk MSDN Architecture Webcast: patterns & practices Live: Test Driven Development, and Kent Beck’s book Test Driven Development.
So if you think this all sounds great, and you decide to give TDD a go, be prepared for a challenging journey. When the pressure is on, you will naturally fall back into your old ways of doing things. You will probably be slower than usual, and feel like a beginner again, and be concerned about all the “extra” code you are now writing. As pressure mounts try and stick with it. Remember, no one said changing old habits would be easy, and one day I may have even broken my own.
Remember the wise words of Master Yoda: “You must unlearn what you have learned. … You must confront Vader. Then, only then, a Jedi will you be.”
