Comment Re:Quality (Score 2) 196
I love unit tests as much as the next refactoring junkie, but there are very significant areas in quality assurance that TDD should not and cannot address, for instance software with emergent behavior.
I've been the unlucky maintainer of monstrous "unit tests" that were instead huge fixtures that create an alternate universe to production. Devs would write code, then spend as much time or more getting the "unit tests" to work, then have QA find brand-new bugs.
The TDD response is decomposition, but some solutions simply do not decompose well. If your s/w is well-architected, the complex parts can be built atop solid APIs that are 90+% covered by real unit tests; the complex functionality can then be exercised in regression tests and simulations, and their invariants verified in QA.
Which brings up my problem with the statement "ensure that QA doesn't find anything": if that's consistently true then one of the following is also true:
* the software is too simple to even warrant QA and indeed should be entirely automated
* the QA process misses huge chunks of functionality
* your software hasn't had a major new feature in, like, forever
* you don't have a GUI (or your GUI has a locked-down platform)
* your developers intimidate and harass QA so they are loath to really test
Effective QA finds bugs, that's what they do, and they are a godsend to a good development team.