TDD misconceptions

Developers have different opinions when it comes to TDD. Most developers do complain about the time and resources required to practice TDD fully and how practicing TDD might not be feasible, based on tight deadlines and schedules. This perception is common among developers just adopting the technique, on the premise that TDD requires writing double code and that time spent doing this could have been used to work on developing other features, and that TDD is best suited for projects with small features or tasks and will be time-wasting with little return on investment for large projects.

Also, some developers complain that mocking can make TDD very difficult and frustrating, as the required dependencies are not to be implemented at the same time the dependent code is being implemented but should be mocked. Using the traditional approach of testing last, the dependencies can be implemented and all the different parts of the code can be tested afterwards.

Another popular misconception is that in the real sense tests cannot be written until the design is determined which relies on code implementation. This is not true, as adopting TDD will ensure there is a clear-cut plan on how the code implementation is to be done, which in turn gives a proper design which can aid the creation of efficient and reliable tests for the intended code to be written.

Some folks at times use TDD and unit testing interchangeably, taking them to be the same. TDD and unit testing are not the same. Unit testing involves practicing TDD at the smallest unit or level of coding, which is a method or function, while TDD is a technique and design approach that encompasses unit testing and integration testing, as well as acceptance testing.

Developers new to TDD often think you must completely write the tests before writing the actual code. The reverse is the case as TDD is an iterative technique. TDD favors exploratory processes where you write the tests and you write enough code. If it fails, you refactor the code until it passes and you can move on to implementing the next feature of your application.

TDD is not a silver bullet that automatically fixes all your bad coding behaviors. You can practice TDD and still write bad code or even bad tests. This is possible if the TDD principles and practices are not correctly used, or even when trying to use TDD where it's not practical to use it.