How Tests Support Refactoring
I have witnessed programmers express annoyance about how tests seem to interfere with changing production code. A discussion on this topic led here:
In particular, it raised this commonly-heard expression of frustration in the vein of “Ask Why, But Never Answer”
Aren’t tests supposed to make refactoring easier???
Isn’t that better? You can let go of this expectation now. May you be at peace.
Tests make refactoring safer, but not necessarily easier. Sometimes, by accident, they do both.
If you judge that the safety is no longer worth the investment, then you can safely throw the tests away. This carries the risk of committing early to “rolling forward” (or going back and trying again), but throwing away the tests is always safe in the sense that doing this must never break production code.1 At worst, it makes changing that production code more expensive—a risk that you can manage in a variety of ways.
But if you’re expecting tests to (generally) make refactoring easier, then you’re expecting too much. Nothing can (generally) do that. You’ll have to settle for making refactoring less risky in other ways, less expensive overall, and ultimately less stress-inducing. Tests certainly help me do that, at least on most days most of the time.
I use “must” here precisely and deliberately. Not “should”, but must. If you break this rule, then you have more-urgent problems. Plz fix.↩︎