Doing TDD the wrong way

As interesting as practicing TDD can be, it can also be wrongly done. Programmers new to TDD can sometimes write monster tests that are way too large and defeat the purpose of test brevity and being able to perform the TDD cycle quickly, leading to a waste of productive development time.

Partial adoption of the technique can also reduce the full benefit of TDD. In situations where only a few developers in a team use the technique and others don't, this will lead to fragmented code where a portion of code is tested and another portion is not, resulting in an unreliable application.

You should avoid writing tests for code that are naturally trivial or not required; for example, writing tests for object accessors. Tests should be run frequently, especially through the use of test runners, build tools, or continuous integration tools. Failing to run the tests often can lead to a situation where the true reflection of the state of the code base is not known even when changes have been made and components are probably failing.