As much as I appreciate your praise of TDD here, there are large categories of defects that TDD does nothing to prevent. TDD only helps programmers write the code they intended to write. It doesn't protect against programmer misunderstandings.
As a result, well-TDD'd code may still have defects that involve:
- the programmers misunderstood what needed to be built ("requirements" defect)
- the programmers interfaced with an external system that behaves differently than they thought
- the programmers used a third-party library or framework incorrectly
- there is a systemic error in the programmers' approach to the problem (e.g., not knowing about SQL injection attacks)
As I say in my "Let's Play TDD" series (http://jamesshore.com/Blog/Lets-Play/), TDD does a great job of helping a programmer write the code she intended to write. But it can't check the programmer's fundamental assumptions, so it's still important to check those assumptions using other techniques.
Agree with all of this, and I've made the same arguments myself. That's one reason code coverage metrics are of limited use -- they can't measure the quality of the tests.
I wasn't intending to diminish the role of QA (essential) or assert that TDD cures all (doesn't), just that The Black Team weren't doing TDD.
As a result, well-TDD'd code may still have defects that involve:
- the programmers misunderstood what needed to be built ("requirements" defect) - the programmers interfaced with an external system that behaves differently than they thought - the programmers used a third-party library or framework incorrectly - there is a systemic error in the programmers' approach to the problem (e.g., not knowing about SQL injection attacks)
As I say in my "Let's Play TDD" series (http://jamesshore.com/Blog/Lets-Play/), TDD does a great job of helping a programmer write the code she intended to write. But it can't check the programmer's fundamental assumptions, so it's still important to check those assumptions using other techniques.