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
2004.Sep.23 Thu
Reasons to do Unit Testing / TDD / Automated acceptance tests
1. There are studies/statistics that say unit testing finds 70% of the defects.
2. A unit test provides an example of what a piece of code is supposed to do. Going through the code in the debugger only tells you what it is doing, not what it is supposed to do.
3. You can run hundreds of unit tests in the same amount of time it takes to go through one function in the debugger.
4. Unit tests as change-detectors - you've changed one line of code in a million-line system. Did you break anything? Run the automated unit and acceptance tests and find out. (If you've done strict TDD, your tests have nearly 100% code coverage.)
5. Unit tests as documentation -- multiple examples of what the code is supposed to do, and how it should handle failures.
6. Test-driven development is a thinking/designing process that happens to leave you with a bunch of tests. You can do the same thinking/designing process without TDD, but you don't end up with any tests.
7. Exploration. You can try out an unfamiliar API in a test, preserving a record of what that API does (and notifying you later if the API's behavior changes.)
8. Making code testable improves its design - making it more modular and encouraging you to make it more cohesive.
Given all these points (especially points 1 and 4), why would any company that is trying develop software to satisfy customers demands allow its programmers to NOT do unit testing and automated acceptance testing?