> "Trying to improve software quality by increasing the amount of testing is like try[ing] to lose weight by weighing yourself more often." I realize this is p

> "Trying to improve software quality by increasing the amount of testing is like try[ing] to lose weight by weighing yourself more often." I realize this is probably here to provoke a reaction, but it's still retarded and it's obviously wrong for the obvious reasons. > You are writing code to test something that doesn't even exist yet. I am not rightly able to apprehend the kind of confusion of ideas that could provoke such a method. I agree TDD can be taken too far and be enforced too strict (although I've yet to encounter that in practice). That said: It's not stupid to write tests before the code which you are supposed to test. The order of these things are here for a reason: If you don't write your tests before you have working code, how do you know your tests will detect a failure mode, and thus can be used to prove that your code is now working? Just the other day I thought I had fixed a bug, and then proceeded to write a unit-test for it. The unit-test went green and I was happy. But then I decided to comment out my fix and re-run the test. I assumed it probably wasn't needed. I was confident and knew after all that I had "fixed the bug". But that way I could at least say I had followed the TDD mantra, which claims to be there for a reason: 1. write test to reproduce bug, 2. write fix, 3. rerun test and if green 4. commit. Upon commenting out my fix and "needlessly" rerunning the tests, lo and behold: The test was still green. My test failed to detect the error-condition. Which meant that my patch had probably not fixed the reported bug. Quality had not improved. I rewrote the tests and managed to make them go red, that is, detecting the failure mode. Uncommenting my fix and rebuilding, my test was still red. My fix was indeed invalid! Another round of investigation showed that I had misinterpreted the error condition and produced a "fix" which didn't solve the real problem. And the "stupid" principles of TDD helped me detect a invalid fix, find the real issue and verify a real fix for it. TDD helped me increase quality. Stupid indeed, eh?