It's been over a year now since I have been developing using TDD (Test Driven Development) as my primary development practice. I wanted to reflect on what it has done for me professionally. In reality, the past year has been great for my professional career in many ways.
I started out in August of 2007 with what I THOUGHT was TDD. Sure, I wrote my tests before my code, but the philosophy behind it wasn't enough to be effective. It wasn't until I went to Boston for a 3-day seminar on TDD taught by Rob Myers of NetObjectives that I really understood the power and relevance of TDD. His challenge was simple -- Try it completely for 30 days. If you don't find the value in it, then move along and look for something else.
So, this is what I did. I spent 30 days practicing TDD the way Rob taught us. I followed the following algorithm:
- Write a test
- Watch it fail
- Write the MINIMUM necessary to make it pass
- Watch it go green
- Refactor if necessary
To be honest, it was a real exercise in self control. I wanted to take shortcuts. I wanted to write some behavior while I was there, and write the tests afterwards. But I promised myself that I would stick through it and write all of my new code in this way.
The benefits were immediate and profound. My methods were smaller. My classes were cohesive. My design is more extensible. My code was more readable. My classes were not tightly coupled. My units were testable, and my tests ran fast. It was amazing how quickly the prophecies of TDD came true.
After a year of this practice, I can honestly state that my code has less bugs. Moreover, when a bug is found in my code, I am able to write a new test immediately (due to the heightened testability of the code) that exercises the bug. Fixes happen quickly and I have a great deal of confidence that my fix doesn't break something else. I certainly can't say that about my legacy non-TDD code.
It is funny. I often feel like a born-again evangelical when it comes to TDD. Like a wide-eyed Christian who is eager to spread "the good news" every time somebody has a personal problem, I am quick to suggest TDD whenever I hear somebody talk about a coding problem. I am not the first (nor the last) to liken TDD to religion. It is fitting:
"For Kent Beck so loved the developers, that he gave his most precious tool (TDD), that whosoever believeth in it should not write legacy code, but have everlasting code." -- Agile 3:16
All kidding aside, TDD has really changed my professional life. In the past year, I have met many colleagues who share my beliefs and there is a real community out there. I have become so passionate about the topic that I am even giving public talks on testing and TDD. Without TDD, I would probably be stuck on the plateau where I sat -- stagnant and stale. TDD was the kick in the ass I needed to grow as a developer.
Looking back, I couldn't be happier with my experience in Rob's class. He taught me what I was doing wrong, and helped me do it right. It takes someone who really KNOWS TDD to teach it to someone who doesn't. I would recommend this experience to any developer in a heartbeat.