The shortest possible description of TDD is actually the term itself. It is self-containing. It is describing that, by using this as your methodology for your software application development, the development will be driven by tests. Tests need to be defined to drive the writing of your application code, and in this way, your tests are directly derived from the requirements. This is an often uttered one-liner to describe TDD in a nutshell:
The ultimate consequence of this is that you will never build application code that does not have tests to it. And, as the tests are one-to-one related to the requirements, your application code should not have any undocumented features.
But this description is actually not the basic definition of TDD. TDD is defined only by the following two rules, and everything else is deduced from that...
