As his final bow in this section, Beck writes a new test case for TestSuite.
A couple things stand out here.
First, the notion that TestCase/TestSuite is an example of the Composite "design pattern" is not something that is falling out of the test -- it's an insight that Kent Beck has because he has written multiple xUnit implementations already. The TestCase code doesn't currently conform to that pattern because Beck was pretending that he didn't know this.
Because he got this far before "discovering" TestSuite, he has a small pile of work to redo - in this case, nothing high risk (toy problem, he has tests, he understands the change, he didn't let the original implementation stray too far from where it was always going to end up, and so on).
That's the happy version - the change happens before the code really starts to ossify.
What this brings to mind for me is Jim Coplien's observation (Beust claims it is an exact quote, but I haven't been able to verify that via the provided transcript) about YAGNI leading to an architectural meltdown.
Here, we have relatively little investment the old idea, so the cost of change is pretty trivial. But this example may not be representative of the general case.
Second - are we sure that the design that is emerging here is good? The story ends in sort of an ugly spot - there's a lot of work left to do, although not necessarily any new lessons. Don't confuse "these are the things we do" with "these are the results we settle for".
Which I think is unfortunate, in that one of the communication gaps I see is that people don't share the same understanding of how much remove duplication is supposed to happen before you move on.
Possibly interesting exercise: see if you can get to pick your favorite moden python testing framework without binning this work and starting fresh.
No comments:
Post a Comment