Practicing TDD provides the cadence for building software, and it also gives developers a safety net for building code. You could discount the idea of a safety net, but it’s just as important for software developers as it is for an acrobat. Who would go up on the trapeze five times a day knowing that one small slip would be her last? Having that safety net is psychological assurance. It bolsters the confidence needed to try stuff and gives you the freedom to experiment that leads to true innovation.
The greatest of the many benefits of doing test-first development is the end result: software developers are writing more testable code, which costs less to maintain.
Developers who are practicing test-after will sometimes discover in the process of writing tests later that they have to change their code to make it more testable. Doing that first, because you’re writing the test first, is much more efficient. You never have to rewrite code for testability when you’re doing test-first.
So even though it is against conventional wisdom, which says you should create the test after there is something to test, it makes a lot more sense to start by writing the test first. Similarly, most developers have been taught to start with the design, but it turns out that you’ll know much more about the right design late in the project. So I’m a proponent of another practice that goes against conventional wisdom: implementing the design last. This is the topic of our next chapter.