There are rules that we follow in TDD, when TDD is done right. It is simple, but it requires discipline. Typically, most programmers feel they are smart enough to skip a few steps ahead. I know. I was one of them. Until it came back to bite me. Then I started holding myself to these simple rules:
Write new code only if an automated test has failed.
You are not allowed to write any more of a unit test that is sufficient to fail, and compilation failures are failures.
You are not allowed to write any more production code that is sufficient to pass the one failing the unit test.
Never modify production code without a failing test unless you are in the refactoring step.
Treat your tests like you treat production code. They should live with the code in the same project and be committed to the same VCS repository.
Your tests, like your code, should be small and have one responsibility. Avoid multiple asserts that test multiple conditions in a test. Instead, write another test.
Run your tests often. After every change and/or refactoring.
(this is taken from my blog. Sources are cited in the blog, TDD. You're Doing It Wrong..