Some Pitfalls Of Test Driven Development
Everybody seems to love TDD (Test Driven Development). Writing unit tests can be a lot of fun, and a real productivity enhancer. Writing tests before writing a piece of code is also a great idea. It sure helps you shape your interfaces and think about their usability even before implementing them. It also has the benefit of documenting the requirements as you (the developer) understand them in a technical language (a programming language).
However, there are some pitfalls in the TDD methodology which you must beware of. Let’s use this attractive diagram (from the IDP blog) as a reference.
Caution! Rework Ahead.
According to the TDD practice, the first thing you should do after writing the test is causing it to pass. TDD advises you to do that using the minimum work needed. In other words: Write! Don’t think! Don’t worry, a couple of stages further down the line you will refactor the code you’ve just written to make it usable. You might even improve its design.
No matter how you call it, this is just a structured (and planned) rework. Now, please don’t get me wrong. I have nothing against Refactoring. However, I believe Refactoring should be used to fix bad code or code which no longer answers your needs. Writing bad code deliberately, knowing that you are going to refactor it shortly is useless.
The idea that writing quick and dirty code and fixing it later takes less time than writing the code well to begin with is fallacy. If anything, fixing bad code (even if it works) is a time consuming activity.
If you know what you need to implement, and you know you need to produce good code at the end of the process, it is by far more cost effective to write it well to begin with.
But that’s not all…
The Tight Schedule Syndrome
An even bigger pitfall is also derived from the same partitioning of work: writing the code to pass the test and only then rewriting it to meet your quality standard.
When you partition every development task into two, there is a chance that you would be tempted to leave the code in a bad shape because of the tight schedule you are under. It is, after all, working as expected, isn’t it? Why do some work which is not delivering any new functionality?
This pitfall can be avoided with proper education: explaining your developers that the quality of the code is as important as the functionality of the product. But wouldn’t it be better to educate your developers to write the code well to begin with? Developers who are used to writing good code fluently will never be tempted to write bad code just to make a test pass. Writing good code will become part of their nature.
The Bottom Line
The bottom is: don’t stop practicing TDD. If it works for you and improves the way you develop software, keep doing it. However, you can shorten the process and avoid some pitfalls by writing good code to start with. This is not to say that you will not need to refactor your code. But don’t plan to do that deliberately if you can avoid it.
March 28th, 2006 at 12:41 pm
While I can almost agree with your “Bottom Line”, I don’t agree with the section “Caution! Rework Ahead.”.
Test “Driven” Development simply means that the thinking goes into the tests not the code. It’s the quality and sequencing of creating and changing the tests which induces the initial quality of the code. If we have a “grand plan” for good code in mind nobody prevents us to write and change the tests in such a sequence that we are forced to produce exactly the code we have in mind. Whether that is the most economical way is probably different for every programmer.
March 28th, 2006 at 4:00 pm
I agree that for some developers writing good code to start with is not the most economic way… yet. If you can teach these developers to write good code to start with (or create good designs for that matter) you will achieve higher optimization of their work: more value for less cost. This is not only possible, but even essential in order to reduce development costs.
June 26th, 2006 at 6:39 am
I really like your blog, you’ve got great stuff in here! :)
I’m just a beginner in TDD myself and trying to incorporate it in my work now. I read another blog with a post on TDD that explains the reason for first making the test fail and then making it pass. It really made me understand the reason for this process. This site also has quite a few good blogs on this topic, in case you or your readers are interested. Here’s the link:
http://codebetter.com/blogs/scott.bellware/archive/2005/11/22/134954.aspx
It really showed me the light with the ideas of TDD. From all I’ve read so far about it (which has mostly been from blogs like these), it seems to be a great design methodology - if done right! Isn’t that always the hardest part? I guess it’s something like how you talk about the hijacking of the word “Agile”!
Thank you again for all the posts, I enjoy reading them!
August 11th, 2006 at 6:13 am
Lidor,
If you can teach developers to write good code to start with, and they habitually use TDD, then their projects will enjoy the benefits of both. TDD is not a substitute for knowledgeable software engineering. It’s a technique for building clean, well-tested code and for paying off design debt incrementally.
Planning to refactor deliberately is not an error, and not an indication of poor initial design or code. No one writes “bad code” on purpose “just” to make a test pass. It is natural for a codebase to become messy as functionality is added to it. Incremental refactoring as part of the red-green-refactor cycle is a way to keep the codebase clean as that occurs.
TDD is an evolving discipline, and not a static practice. Presently, two areas of improvement that are gaining traction are (a) behavior-driven development and (b) refactoring to patterns. The former requires developers to think, design, and act as business analysts before writing anything. That leads to well-considered, clean designs that accurately reflect requirements, and to tests that reliably demonstrate that requirements have been met. The latter combines pattern-based design, recognition of code smells, and sound software engineering practices with TDD’s red-green-refactor cycle. That leads to high-quality, maintainable code with few defects.
It isn’t a question of whether TDD works “for you,” it’s a question of whether TDD works “for software development.” It does. If TDD doesn’t work “for you,” you will find the reason in the mirror.
Your blog is all about optimizing software development. TDD is one of the most effective tools for doing so. It’s all the more powerful in the hands of knowledgeable, highly-skilled developers. By treating TDD as if it were merely a workaround for ignorant or careless developers, you may be overlooking or undervaluing a very useful and practical tool for optimizing our work. Be careful not to get carried away by the anti-agile “backlash” people are talking about these days, and forget your own goals. ;-)