It is easy to find a definition of Test Driven Development (TDD):
I see TDD as starting with an English statement, or test, which is False but should be True.
I make the test True with a small piece of software.
The test 'drives' development of a small piece of software.
I build a modular application from hundreds or thousands of small pieces of software, and each of them is birthed by a corresponding test.
For example, before I wrote the page which you are reading, I wrote this statement:
This page: http://ml4.herokuapp.com/cclasses/class01td should describe TDD.
After I wrote the page, the above test switched from False to True.
It is obvious, to me, that every test which drives development should start life as an English statement.
For many applications, I stop there; I do not transform the English tests into Software tests.
For some applications, I will transform the English statement into syntax which alerts me if a piece of software starts failing.
For example I could start with this English statement:
Everyday at 2pm the page http://ml4.herokuapp.com/cclasses/class01td should return a status of 200.
I might then transform that English into software which uses syntax like this:
/usr/bin/curl --head http://ml4.herokuapp.com/cclasses/class01td|head -1
I see those as the big ideas behind TDD.
When I develop the software tests which drive the development of an app, I often bump into many devilish details.
Implementing TDD is not easy but the main ideas behind it are comprehensive: