The Third Virtue

Unit Testing is boring and tedious.  This is not just a hyperbolic opening line with the thinly veiled intent of grabbing the reader’s attention.  The only times I can remember enjoying writing a unit test were cases where there was a short setup to a not-quite-trivial problem, leading to the application crashing, such that writing out a unit test is not only less annoying than a manual scenario, but in some small way, I feel like I’m giving the buggy code the finger by not letting it inflict its full potential for disaster.  I am only four, after all.

Now is when the Hubris comes out.  How can we improve this situation?  Unit testing is not only recommended, but is indeed part of being a software professional.  If code you’ve written doesn’t have some automated testing around it, I would like you to have at least considered it, and made the conscious decision not to, for a good reason.  Otherwise, you’re not doing your job properly.  It’s really that simple.

I’m far from perfect – I whizzed through a bunch of issues during one sprint, doing more than either of two very capable and more senior developers than I and when they commented, joking, that I was making them look bad, it struck me instantly and I said “Yeah, but mine aren’t unit tested – yours are”.  Because sometimes, I would rather syringe my own infected wisdom tooth extraction cavity than write a test which confirms that under the right conditions a field or two are validated such that a boolean is flipped.

But that’s it, isn’t it.  Some other capable programmer had come along and mis-matched the whole set of conditions under which True (yes, this is VB.NET code) should be returned.  It wasn’t some script-kiddie who didn’t have a clue what was going on, it was a full blown software professional.  And they failed to return the correct value of a mere boolean.

The purpose of Unit Testing is more than just proving code correctness, it’s about communicating a conscious decision to make the code act a certain way.  It’s about laying down an executable set of requirements – somewhere where developers will actually pay attention.  And it’s about security.  It’s such a liberating feeling having a bunch of unit tests solidifying the code beneath you, allowing you the freedom and pleasure to refactor, rather than bolt another pimple on a pumpkin.

But as I asked in a previous post, how do we make it pleasing to do this laborious work? One word; Gamification.  Yes, the spell-checker throws its toys at it, but google knows what I mean, so I’m pretty sure it’s a real thing.  Writing code is a group activity – most of us accept this quite readily.  Let’s leverage that into a testing game.

This is, however, where my post all falls down.  I haven’t worked out a decent way of measuring Unit Tests – which is the essential building block of a Game.  Goodhart’s Law tells us that whatever we measure is going to become worthless anyway, so ideally it would be something we can’t fake.  I.e. there needs to be a standard, accepted measure of quality, along with quantity (and certainly a bonus for breaking new ground).  Lines covered is not even close to being enough.

It’s far too easy to have terrible quality tests which touch many lines, that end up being worse than no tests, because they give a false sense of security, whilst also having a maintenance cost.  Are we professional and trustworthy enough to not write crappy tests.  I’d actually like to think so.

I’m guilty of not always doing my job as completely as I’m able.  I don’t always write automated testing around my code.  But I’m trying to do better (see how I brought it back to Hubris?).  I’m trying to come up with the right recipe to remove the chore of unit testing.  So I’m not going to beat myself up too badly every time I check in some manual-only tested code, because I will do it again – probably as soon as tomorrow.  Now I just have to work on the rules of the game.