I've been trying to evangelize Test Driven Development (TDD) for quite a while now and come to the conclusion that in order to really appreciate it you need to fully commit to doing it properly. It won't really hit you the first day, first week and may take more than a month but at some point you will hit that moment when it just feels wrong to write code without first writing a test for it.
During a code review once I saw a very simple test for some very simple code and was asked by my peer reviewer what is the point of this?
I hadn't written either the code or the test and looking at both I didn't see the need for the test at all, it wasn't until afterwards I realized that the original coder was most likely doing TDD properly though. If you don't start with a breaking test then you're not doing it right so even very simple code should have at least one test.
Since that day I've taken on some very complex projects and continued my quest to convert fellow software developers over, without much success but I'm still trying. I have also written code using TDD in less than a day that I'm pretty sure would have taken me well over a week to finish and debug had I not followed TDD from the start.
I found this free talk by one of the best proponents for TDD there is, Uncle Bob and he does a great job of explaining this along with a Code Kata to show how TDD is really done: Advanced TDD by Uncle Bob.
In this talk Uncle Bob mentions the The Transformation Priority Premise and this is very important to consider while practicing TDD so here's a couple links to help explain this further:
If you are a TDD convert please pass along these links to anyone you know starting out with TDD. If you're not a convert yet give it an honest try and don't give up when you're pressured to "finish quickly". If you stick with it you will have solid reliable code that breezes through QA so any of that time you feel is lost writing your tests will be recovered by time you don't have to spend hunting down hard to find bugs.
Post a Comment