Listen to this post
When a test precedes development, it essentially becomes the first “client” for the behavior being developed. This fact is helpful in several ways.
First, the interfaces TDD drives into the system are always client-focused. They are not implementation-focused because at the moment they are created there is no implementation yet. In their seminal book on Design Patterns, the Gang of Four recommended, among other things, that we “design to interfaces.” TDD promotes this in a fundamental way.
Also, the tests themselves provide a glimpse into the qualities of future clients. For example,
- Are the tests tightly coupled to the system? Future clients will probably have the same issue.
- Do the tests contain redundancies? It’s likely we’ll have the same problem in client code we’ve yet to write.
Identifying these issues early helps us to avoid or correct them before they propagate, reducing the refactoring burden on the team.
Anything we do to improve the quality of the tests will also promote that quality generally throughout that system. Tests drive quality issues into the earlier decision-making process, and thus reduce waste and promote clarity.