This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Reasons to do Unit Testing / TDD / Automated acceptance tests
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
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?
Previous Topic
