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
- Repeat
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.
Amen
5 comments:
Hi,
Your great done! I really to try TDD, but I don't know where to start. I know about the concept and have some tests in NUnit, but I'm not sure how to apply it into my project. Any advices?
Samnang
Samnang,
I am happy to help you out. Email me directly -- BrianGenisio at Gmail and we can talk!
Brian
When I've done TDD in the past, I've found that my code generally reflects my thought process when I was developing the unit tests. What I mean by that is that often find myself writing code to satisfy the unit test in the order that the unit test was created. I'm exaggerating to an extent, but what I found myself having to do is one final and major reactor of the code, which has honestly been an almost complete rewrite of the functionality. I do, however, agree that the overall quality of my code has increased because I have taken the time to thoroughly test it before it has been released into the wild. Additionally, I'm much more confident about future refactoring.
Not that you suggested otherwise, but one thing that I want to point out is that I personally found doing TDD takes longer than not doing TDD. Additionally, for some reason, I find that it often takes longer to write the unit tests than it does to write the actual functionality.
What a great post. Thanks for this... I passed it along to my entire team.
I agree on your sentiments about TDD. I have been using it only about eight months or so actively but I can understand the difference.
Probably the biggest thing it has offered for me is the confidence in refactoring (see Fowler) the code. I don't have to fear that things start to break up that easily.
The thing with TDD is that you have to maintain your tests (see Clean Code by Martin) or else you end up with something you eventually have to dump. This is a small price to pay for the good sides of TDD though.
Post a Comment