Refactoring Strategy: Move It Where You Can Test It | #54

When I can't test it where it is, I look to move it somewhere else, where I can test it. Today's notion isn't so much a single refactoring as it is a strategy that can be achieved in different ways (and different multiple steps). A modern and frequently occurring case: using a cool framework to expose service endpoints, we write a function and then we annotate it and poof, it's an endpoint. This is how Java+Swing works, or Python+Flask. When we give that function a body, it will be a body of "our branching logic" (OBL). We've already discussed that OBL is the main target of our tests, so we definitely want to test that function. Sadly, testing that usually involves one or more of three owwies. We'll have to either/or/and 1) fire up the app, 2) fire up the framework's test rig, 3) instantiate the class containing the method. Most of the time, none of these three choices is a fountain of geek joy. The problem, in all three choices, is in the weight of that framework. And it's not a problem that's avoidable: we chose that framework precisely cuz it does so much for us. Of course it's heavy. --- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.