RE4. Even if 100-percent test coverage (see RE3) were possible, that criteria would be insufficient for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent are from the execution of a unique combination of logic paths. They will not be caught by 100-percent coverage (100-percent coverage can, therefore, potentially detect only about 25 percent of the errors!).
Given the fanaticism for TDD today, this is a fact well worth remembering.
TDD is not about finding defects, its about minimizing work (you code to pass tests and no more - as a side effect, you should always have 100% coverage) and about preventing working code from being broken through bug fixes, refactoring, or extension because your existing tests will then fail. Its a guarantee that what works now will still work later - or the test will fail, not the test will find bugs.
I wish all TDD proponents understood this. Coverage != Tested. 100% coverage does not mean you have have exercised all possible execution paths through the code.
Also, passing all tests does not mean there are no bugs. Assuming you have tests for all your requirements, passing the tests means only that software can perform those requirements. It does not mean that it will be bug-free, especially if the users try to do things the requirements didn't anticipate.
TDD has the great benefits you mention but it is not the magic bullet so many of its advocates make it out to be.
From the context he seems to just be talking about code coverage as a metric, not TDD (though maybe he goes into more detail in the book?).
TDD claims to lead to higher coverage but I guess they'd claim to help you avoid missing logic paths too. Since you start with tests and then write code so that you've always got high coverage. If you've not written a test for it then you can assume that it doesn't work. The alternative is to
write a bunch of code, then add just enough tests to keep a coverage metric happy.
RE4. Even if 100-percent test coverage (see RE3) were possible, that criteria would be insufficient for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent are from the execution of a unique combination of logic paths. They will not be caught by 100-percent coverage (100-percent coverage can, therefore, potentially detect only about 25 percent of the errors!).
Given the fanaticism for TDD today, this is a fact well worth remembering.