Listen to this post
Project Managers and Product Owners are sometimes dubious about the development team doing TDD. They are concerned that the team will slow down because they’ve been burdened with additional work, and that developers might “game” the system with bogus tests to satisfy the process. Also, it seems like a nonsensical idea to write a test for something before that thing exists.
All of these concerns are addressed by the observation that, despite its name, TDD is not really a testing activity. The “tests” that are written in TDD are actually the specification of the system.
The effects of this shift in thinking are profound.
First, it is not at all odd to think of the specification preceding development. Specification has always come first. Second, it is not a new task but an old task done in a new way, and a better way because the specification can be executed against the code. Also, developers would never “game the specification,” because they value it highly; the spec tells them what to do, and leads them to success. Everyone wants to succeed.
Finally, TDD does not replace traditional testing. So the testers are not removed from the process, they are simply given more time to do their job.
TDD provides value to everyone in the development process.