TDDbE: Money Retrospective

The biggest surprise for me in coding the money example was how different it came out this time.

In other words, the design isn't something that merges organically from the test; the tests and the design co-evolve under the guidance of the programmer.  If the programmer has an inspiration, then the programmer writes different tests to constrain the behavior of the implementation, and then the implementation follows.

The tests that we have in this example are not metaphor agnostic, as a review of them will show.  They are a sort of long term bet that this metaphor will stick in this code base.

The tests that are a natural by-product of TDD are certainly useful enough to keep running as long as the system is running.  Don't expect them to replace the other types of testing.

I'm reminded of Coplien's comments about unit tests and changing signals; we should think carefully about how much we want to invest in keeping these tests running as the system changes.  In this toy example, the code isn't finished - we'd likely want to keep the tests around while the system was under development, because that tells us something important about the changes that we are making.

JProbe reports only one line in one method not covered by the test cases -- Money.toString(), which we added explicitly as a debugging aid, not real model code. [emphasis added]

It seems to me that much of the extremism of TDD has built into it the idea that our focus is on model code, rather than on effects (especially true of the "classical" school).

Removing duplication between test and code as a way to drive the design

I'm happy to see this message reinforced again, but I'm not sure its useful - until you see it, you don't see it, and you can be doing TDD for a long (long) time without seeing it.