Listen to this post
Part of the TDD process consists of writing failing tests before the code that will eventually make them pass. Test-first alone is not TDD per se, but it is a part of it.
When tests are written before production code, this has several beneficial effects. This comes from the fact that these tests have the same orientation toward the code that client code will have in the future. Tests are, essentially, the first clients of any behaviors they drive into the system.
Here are some of what this means.
- Interfaces will be driven from the clients’ needs. This is compatible with the Gang of Four recommendation to “design to interfaces.” This, in turn, promotes the separation of concerns.
- Tests will identify any vulnerabilities that clients will experience beforehand. For example, if the test needs to use magic numbers in order to execute, this tells you that clients will have to do the same thing. Improving the test by adding constants to the code will also benefit clients. Of course, these constants should also be test-driven.
- Redundancies in tests that cannot be factored out is a warning that future clients will contain redundancies.
These are just examples. TDD causes us to develop behavior from “the outside-in.” This enhances reusability and limits coupling.