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
2005.Oct.10 Mon
Robert C. Martin writes on the benefits of TDD-style unit tests (bold-facing is my emphasis):
Have you ever integrated a third party library into your project? You got a big manual full of nice documentation. At the end there was a thin appendix of examples. Which of the two did you read? The examples of course! That's what the unit tests are! They are the most useful part of the documentation. They are the living examples of how to use the code. [...]
[...] I had been a programmer for nearly thirty years before I was introduced to TDD. I did not think anyone could teach me a low level programming practice that would make a difference. Thirty years is a lot of experience after all. But when I started to use TDD, I was dumbfounded at the effectiveness of the technique. I was also hooked. I can no longer concieve of typing in a big long batch of code hoping it works. I can no longer tolerate ripping a set of modules apart, hoping to reassemble them and get them all working by next Friday [...]
Robert C. Martin compares test-driven development to double-entry bookkeeping:
Software is a very sensitive domain. If a single bit of a 100MB executable is wrong, the entire application can be brought to it's knees. Very few other domains suffer such extreme sensitivity to error. But one very important domain does: Accounting. A single digit error in a massive pile of spreadsheets and financial statements, can cost millions, and bankrupt an organization.
Accountants solved this problem long ago. They use a set of practices and disciplines that reduce the probability that errors can go undetected. One of these practices is Dual Entry Bookkeeping. Every transaction is entered twice; once in the credit books, and once in the debit books. The two entries participate in very different calculations but eventually result in a final result of zero. That zero means that the all the entries balance. The strong implication is that there are no single digit errors. [...]We in software have a similar mechanism that provides a first line of defense: Test Driven Development (TDD). Every intention is entered in two places: once in a unit test, and once in the production code. These two entries follow very different pathways, but eventually sum to a green bar. That green bar means that the two intents balance, i.e. the production code agrees with the tests. This is not perfect, and other controls are necessary; but there can be little doubt that TDD vastly decreases the defect load in software projects. [...]
Robert C. Martin reminds us:
When tests are ugly, maintaining them is hard; and that makes maintaining the production code hard because the tests have to be maintained along with the production code. [...] If you want your production code to be easy to maintain, you must keep your tests easy to maintain. [...] The tests need to be well structured, well designed, and well coded. They need to be readable, understandable, and flexible. Duplication must be eliminated from them. [...]
Test code is what we depend upon for design documentation, correctness verification, design support, and so many other things. Our tests support our refactoring. Our tests give us the courage to make changes. Our tests tell us what has gone wrong whenever we break something. Given that we depend on our tests for so much; doesn't it make sense to treat them well?