> Further, with TDD, this allows a very detailed and complete test matrix to be established, so the end quality can be quite high. TDD is exactly not this. The

> Further, with TDD, this allows a very detailed and complete test matrix to be established, so the end quality can be quite high. TDD is exactly not this. The main tenet of TDD is refactor early and often as you expand on the supported features. You do not write out all the tests up front, because some of those tests depend on the implementation (eg. the way you integrate components). TDD actually requires a very specific approach to testing, and some of the tests that you end up with are completely unexpected because they depend on how did you structure your code. TDD allows you to achieve an excellent level of quality, but it does not presuppose any "detailed and complete test matrix", because that defeats the purpose. If you do have very precise requirements, they'd usually be expressed in end-to-end tests that are commonly not done as part of a TDD workflow (even though they are crucial when it comes to scaling your team size). TDD only ensures that "internals" of your codebase are healthy, and that it's easy to refactor when requirements change. If requirements don't change that often, TDD might not win you much.