I’ve just read this post about TDD best practices: What Not To Do In a TDD Pair Programming Interview - Software People Inspiring

Although initially focused on pair programming interviews, the recommendations also apply to your day-to-day TDD flow.

Here’s summary of DONT’s:

• start by writing implementation code
• introduce speculative generality (create code we don’t need to pass the tests)
• write weak or meaningless tests
• write redundant tests
• not running the tests
• not refactoring when it’s obviously needed
• hack away at the code when ‘refactoring’
• write one test that asks all the questions