Development with Python

Obey the Testing Goat!

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.

Testing Is Hard

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 psycho‐

logically 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 (I’ll open source it

one day so you can all point and laugh).

Keep Your CI Builds Green

Another area that takes real hard work is continuous integration. You saw in

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

407