About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.Apr.18 Tue
Test driven development (TDD) is a design tool. So is a piece of paper on which you sketch out code. Or a white board on which you sketch out UML diagrams. On a somebody's blog, which I lost the link to, some commenter complained that TDD doesn't force you to do the right thing. Neither do the other tools I just mentioned. These are thinking/design tools.
The design process I go through with white-board, or pencil and paper, or TDD, or just writing code and exercising it in the debugger, is not terribly different for each of these tools. They do have their individual weaknesses: paper or whiteboard means I have to exercise the code in my brain, testing code in the debugger can be slow, TDD tests are not always easy to write.
The key difference with TDD, which is a thinking process that I emphasize isn't too different from designing using the other tools I mentioned, is that after going through this designing-and-coding process, we have unit tests that we can save and run again later. No additional effort required.
Doing design + coding with the other methods does not automatically result in unit tests, so if we want them, we have to make extra effort to write unit tests. And extra effort means things don't get done, or get done grudgingly. This psychological factor is not to be understated: you think you're "done" (coding), so you don't want a failing test to show you that you're not "done". So you don't test very aggressively. In TDD we want the test to fail before we make the test pass, in order to test the test; this is a very different motivation and can actually be fun!
Testing after the fact is more difficult because the code often isn't designed to be testable. "Testable" is a symptom of good design, but rather than seeing that some difficulty in testing is a flaw in our design (which impacts our ego when we think we're good designers), we tend to see the difficulty of writing unit tests after-the-fact as being a flaw in unit testing itself. As a result, many people avoid unit testing, and see experience reports and studies that show unit testing reduces defects and reduces the costs of development as being irrelevant to their situation, or just plain flam-flim and lies.
(By the way, if you design code and unit tests at the same time, that's pretty close to TDD and gets you many if not most of the same benefits. But remember that you and the programmers who do TDD are uncommon programmers.)