Reply to thread

Message: [QUOTE="Phlip, post: 3854340"] Yes. The entry-level aspects of TDD are rapid development with a low bug rate. The high-end of TDD is solid designs that strongly resist bugs. That's QA testing. You get "emergent design", and the bug resistance, via less up-front designing, and more refactoring, triangulation, and fake-it-till-you-make-it. (Definitions below.) And that means people who are not as smart as you need to do much less of the heroic up-front design that you do, to achieve a high bug resistance and high velocity. No - the 10% metric goes from Waterfall or Code-n-Fix to TDD. Not from excessive unit testing to TDD. I think these "well run companies" (ie companies that people like Ian, Noah, or me are not smart enough to run) would still achieve a much higher velocity. And I also question the definition of "bug". If it's "divergence from the specification", then you might be underrepresenting the other definition - "features the users don't like". That rate will go down as your velocity goes up and you deploy more often, in smaller feature increments. results immediately anyway. Yes you do. A TDD project can integrate any code change, and could deploy & release after each 1-line edit. Please don't tell me this is impossible because I have done it. I'm refactoring a big module, my colleague is working on a tiny view change, I integrate, he deploys, and the code works in production for a while with a refactor in-progress in that module. The definitions: Refactoring is not rework, it is making tiny changes to the design, and passing all the tests after each change, until all the changes add up to a new design. (And I could integrate, deploy, or release after ANY of those small changes.) The goal of each refactoring sequence should be code that's more DRY - Don't Repeat Yourself. Triangulation means you guess what design you need, and then you write new tests, each with a different attitude, such that the DRYest code which passes all those tests will express the design you need. Fake-it-till-you-make-it means, after writing a test, you pass it with code with obvious bugs. You know the code would not yet work in production, due to sins of omission. You keep a record of these bugs, and then write new tests to burn out each one. (Note that Triangulation and Fake-It are two sides of the same coin. One refers to design and the other to behavior.) All these techniques force you to write tests that penetrate deep into the logic, and force you to write excessively decoupled and testable code. All as a by-product of going fast. [/QUOTE]

Verification