TDDbE: Change

Describing data with Java is not as easy as it should be, and that's certainly true of Java 2003.  What I'd like to see in a currency exchange test is a list/map of exchange rates, a list of amounts, and a target currency -- without necessarily committing to a specific arrangement of that information into "objects".

But of course, that isn't what we get - we're in the Kingdom of Nouns, and all of the information needs to be put somewhere.

It feels to me as though we're ending up with tests that are more tightly couspled to internal details than I would like - it's somewhat hard to say: are we working toward tests that are describing the published interface of the utilities that are being created? or are we working toward tests that are intended to describe the workings of the utilities to future maintainers.

In modern Java, we might get a better sense for that by looking at what is exported by the modules, but of course we don't have that advantage here (and perhaps wouldn't anyway - I wouldn't want to be introducing a bunch of module ceremony while the interface is still in flux).

I do think it's interesting to watch Beck try to remove the duplication in Bank::rate.  His green bar implementation is a choice between two hard coded values - that's no good, because the hard coded values here duplicate the values in the test.  So he takes a guess at how that duplication should be managed, and creates a new Pair class to manage it.

Note that Pair comes into existence without an isolated test - it's an internal detail of how Bank manages its data structures.

It also interests me to notice that, in this particular case of introducing a regression during a refactoring, Beck's answer is to add another failing test.

The goal isn't to "follow the rules".  The goal is "clean code that works".