Searching online, you will certainly find that TDD is an acronym for Test-Driven Development. We, however, use a slightly more meaningful definition. So, what is TDD? In the simplest terms, TDD is an approach to software development that is intended to reduce errors and enable flexibility within the application. If done correctly, TDD is a building block for rapid, accurate, and fearless application development. 

Test-Driven Development is a means of letting your tests drive the design of the system. What does that mean, exactly? It means that you mustn't start with a solution in mind, you must let your tests drive the code being written. This helps minimize needless complexity and avoid over-architected solutions. The rules of Test-Driven Development

Staunch proponents of TDD dictate that you may not write a single line of production code without writing a failing unit test, and failing to compile is a failure. This means that you write a simple test, watch it fail, then write some code to make it pass. The system slowly evolves as the tests and the production application grow in functionality.

Many would argue that TDD is about testing, and by extension, about test coverage of an application. While these are great side-effects of TDD, they are not the driving force behind the practice.

Additionally, if code coverage and metrics become the goal, then there is a risk that developers will introduce meaningless tests just to inflate the numbers. Perhaps it is less a risk and more a guarantee that this will happen. Let delivered functionality and happy customers be the metrics with which you measure success.

TDD is about design. Through TDD, an application will grow in functionality without introducing needless complexity. It's incredibly difficult to introduce complexity if you write small tests and only enough production code to make the test pass. Refactoring, modifying the structure of the code without adding or changing behavior,  should not introduce complexity, either.