Some things i thought i understood about TDD but didn't:
Starting this process from the very beginning of a project and
applying it very rigidly works best. If you have a working design,
and you keep control of it as a working design, your design is free to
grow with the requirements but will always work.
A nano-increment is the smallest possible meaningful development step
you can take that balances time spent compiling and testing with time
spend coding. Your compilation and test procedure should be fast
enough to keep the conversation between you and the machine in the
flow region. Too little coding per compile-test (or a compile-test
cycle that's too long) and you'll get bored or frustrated. Too much
coding per compile-test and you'll get anxious. Sometimes the machine
will tell you to throw your last nano-increment away; this should not
be problematic for you to do.
Don't add any functionality unless you have added a failing test to
prove that you need it.
Avoid inline functions like the plague. They drastically slow down
the compilation cycle because they limit (or in severe cases
completely curtail) the ability of the compiler to do separate
compilation. It is ultimately to your benefit to live with the fact
that C++ is a twice and only twice language with respect to class
declarations and method prototypes.
Test Driven Development is the art of maximising the work not done.
