Back to the Testing Goat.
'Groan', I hear you say, 'Harry, the Testing Goat stopped being funny about 17 chapters ago'. Bear with me, I’m going to use it to make a serious point.
I think the reason the phrase "Obey the Testing Goat" first grabbed me when I saw it was that it really spoke to the fact that testing is hard—not hard to do in and of itself, but hard to 'stick to', and hard to keep doing.
It always feels easier to cut corners and skip a few tests. And it’s doubly hard psychologically because the payoff is so disconnected from the point at which you put in the effort. A test you spend time writing now doesn’t reward you immediately, it only helps much later—perhaps months later when it saves you from introducing a bug while refactoring, or catches a regression when you upgrade a dependency. Or, perhaps it pays you back in a way that’s hard to measure, by encouraging you to write better designed code, but you convince yourself you could have written it just as elegantly without tests.
I myself started slipping when I was writing the test framework for this book. Being a quite complex beast, it has tests of its own, but I cut several corners, coverage isn’t perfect, and I now regret it because it’s turned out quite unwieldy and ugly (go on, I’ve open sourced it now, so you can all point and laugh).
Another area that takes real hard work is continuous integration. You saw in [chapter_25_CI] that strange and unpredictable bugs sometimes occur on CI. When you’re looking at these and thinking "it works fine on my machine", there’s a strong temptation to just ignore them…but, if you’re not careful, you start to tolerate a failing test suite in CI, and pretty soon your CI build is actually useless, and it feels like too much work to get it going again. Don’t fall into that trap. Persist, and you’ll find the reason that your test is failing, and you’ll find a way to lock it down and make it deterministic, and green, again.
One of the things that helps is to stop thinking of your tests as being an incidental add-on to the "real" code, and to start thinking of them as being a part of the finished product that you’re building—a part that should be just as finely polished, just as aesthetically pleasing, and a part you can be justly proud of delivering…
So do it because the Testing Goat says so. Do it because you know the payoff will be worth it, even if it’s not immediate. Do it out of a sense of duty, or professionalism, or OCD, or sheer bloody-mindedness. Do it because it’s a good thing to practice. And, eventually, do it because it makes software development more fun.
This book wouldn’t have been possible without the backing of my publisher, the wonderful O’Reilly Media. If you’re reading the free edition online, I hope you’ll consider buying a real copy…if you don’t need one for yourself, then maybe as a gift for a friend?
I hope you enjoyed the book. Do get in touch and tell me what you thought!
Harry.