¿ªÔÆÌåÓýI have spent my career looking for ways to do software better - to improve productivity and quality and reduce rework. I tried all kinds of techniques, including formal structured analysis and design, and automated tools whose names I no longer recall. TDD is the first one I have found which actually delivers. It lets me build code more quickly and change it when needed.?I see unit tests as having four main functions: 1. regression detection (much faster than functional tests) 2. supporting refactoring 3. driving development 4. documenting behavior much more reliably than comments Unit tests that were created for the purpose of driving the code tend to be a better job at the other functions than do tests written afterwards for the purpose of improving code-coverage numbers. TDD also leads to software components built as components, with good information hiding. The usual proclivity of developers is to see a problem and immediately search for the algorithms and data structures needed to implement it - and those then become the core abstraction that the codebase must know. A change in algorithm for better performance then becomes a major deal. That should not happen with TDD used properly. ----------------- Author, HttpUnit <http://www.httpunit.org> and SimpleStub <http://simplestub.meterware.com> Now blogging at <http://russgold.net/sw/> Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
|
