Watching Corey solve the kata differently than I would have done has taught me several new tricks. Notably
spec -fs spec — I get a completely unreadable mess when I run that on my own code, so there’s some work to do there in terms of how I name my specs.
Also, my first instinct would not be to extract the
do_replacement helper method. I noticed GeePawHill do that too during his Double Dawg Dare refactoring videos; so it’s common, and a couple of years ago I was doing it all the time. But recently I’ve tried to work the opposite way — if the tests need a helper, I take that as a sign that the API under test isn’t as developer-friendly as it might be. So I look for ways to DRY up the tests by making the test subject’s interface more fluid. The helper method approach certainly gets results more quickly, but I worry about the longer term maintainability of the code; maybe I shouldn’t; maybe I think too much instead of just doing TDD “as if I meant it”.
All of which means that performance kata are a fantastic way to share knowledge, develop new skills and hone techniques. Time for some more practice…