We demand rigidly defined areas of doubt and uncertainty. -- Douglas AdamsWorking through a Fibonacci number kata last night, I discovered that I was frequently using a particular pattern in my refactoring.
What this gives me in the code is clear separation between the use cases that are not currently covered by tests. I can then be more aggressive in the section of code that is covered by tests, because I've already mitigated the risk of introducing an inadvertent change.
The early exit variation I didn't discover until later, but I think I like it better. In particular, when you get to a state where the bottom is done, the branch with the early exit gets excised and everything just falls through to the "real" implementation.
This same trick shows up again when it is time to make the next change easy:
It's a bit odd, in that we go from an implementation with full line coverage to one with additional logic that reduces the line coverage. I'm OK with this; it is a form of scaffolding that isn't expected to survive until the implementation is published.
What I find intriguing here is the handling of the code path that doesn't yet have tests, and the inferences one might draw for working on "legacy" code....
No comments:
Post a Comment