It took me a long time to understand the power of automated testing. After all, it can end up being a large portion of your codebase and can be brittle. Sometimes it feels like writing tests “gets in the way” of getting things done. At one project I worked on, a colleague complained that it felt like you spent 5 minutes changing the production code and an hour changing the tests. (And to be fair, sometimes that’s true, and there’s a balance to be struck between test code coverage and speed of development. This can also indicate you need to spend time refactoring your tests, as you have multiple different test components testing the same production code.)
I like to think of tests like a gentle swaddling of your code. It conforms as the body of your code changes, but changing that code does require some re-work of the tests. And, if your code fails, it fails into the gentle swaddling, as opposed to the cruel outside world (bleeding all over your production users). Alright, maybe the analogy fails :).
I write this today because I’m in the middle of a refactor of one of the scariest bits of The Food Corridor. (Given we’re so young, it’s not that scary, but it’s quite complex–handling the creation and updating of bookings.) There are many many paths through the code and if I didn’t have automated testing, I’d be far more worried about the changes I’m making.
So, consider this blog post to be a thank you to past me for making future me’s life easier by writing a comprehensive automated test suite. If you don’t have one, you should.