Learning Test-Driven Development

Chapter 12. Test Order

My journey has always been the balance between chaos and order.

Philippe Petit

In Chapter 11, we undertook a relatively significant design change by introducing the Bank entity. Both the new test we wrote and the existing tests helped us accomplish this goal.

One feature of the new Bank entity is its ability to accept and store an exchange rate between any pair of currencies. The way we designed (and tested) it—the exchange rates are stored in a hashmap and in the keys formed from the two currencies—gives us reason to believe that we already have the next feature on our list. That feature is to allow exchange rates to be modified.

One way to gain confidence that this feature works is (no prizes for guessing) to write a test to prove it. Why should we write a test when the feature is likely already there? In other words, what could a new test possibly drive, if the development has already been done?

Three answers can be provided to this question:

1. To repeat: a new test would increase our confidence in this feature, even if no new production code is necessary.

2. The new test would serve as executable documentation of this feature.

3. The test may expose inadvertent interactions between existing tests, thereby prompting us to address them.

Tests are an effective way to document our code. Because we can (and should) use meaningful names for our tests, and because they lay out in detail what a feature does (as opposed to how it works), tests are an excellent ...