Doing a refactoring based on a couple of early uses, then having to undo it soon after is fairly common. Some folks wait until they have three or four uses before refactoring because they don't like undoing work. I prefer to spend my thinking cycles on design, so I just reflectively do the refactorings without worrying about whether I will have to undo them immediately afterwards.
I find myself wanting to push back on this a little bit. I don't mind refactoring the measured code on the regular - we learn as we go, and that's fine.
I fret a little bit about refactoring the measuring code; we red-green when the test is new, which gives us additional confidence that the test is measuring what we think it is, but if we are continuing to tinker with the guts of the test we should be recalibrating from time to time.
Which is to say, we red-green on the theory that its not enough to assume that we're measuring what we think we are, we need additional evidence. It seems inconsistent to assume that we can keep evolving the test on the assumption that it still measures what it did before.
Spying on the calls as the framework runs the test is a clever idea, and of course there's no reason that the telemetry needs to be so complicated as an "object".
Got myself really twisted up looking at the final code, until I realized that the code in the text doesn't necessarily match the code he's narrating -- the code in my edition of chapter 20 includes some artifacts that won't be introduced until chapter 21.
Nonetheless, I find myself thinking again that the point is to catch mistakes, not to do The Ritual flawlessly.
A git history with each change following along with the text might be an interesting exercise. Or for this specific example, maybe a jupyter notebook kind of thing.
No comments:
Post a Comment