Unit Testing Is Spooky!

I had a discussion today about the name “unit testing”, and its connotations.

I’d like to remind you, dear reader, that the audience of this blog is already aware of the goodness that comes with unit testing. Unit testing is part of our day-to-day work, and also for people just starting to get interested in becoming professionals.

But what about those poor souls that don’t know what “unit testing” is? Does the term sound frightening to them? When you ask your developer friend: “Have you heard about unit testing?” you probably expect: “No – tell me more about it!”

Only she thinks: “Well, I’m a developer, not a tester”. Or maybe she’s thinking: “Man, this guy is condescending. He’s using a name-of- the-week from the garbage-can of tech-talk. I’m going back to work”. Case closed, your friend now won’t even hear about the happiness that goes along with the name.

The way we talk about our favorite methodology, though we mean good, can have some horrendous results. For your friend, you either wasted her time, or wrecked a relationship.

Is it just the name?

Names of features, products, methodologies, and even people can actually create or lower barriers to acceptance. The term “unit testing” is ancient (in development years) but apparently doesn’t take into account any emotional or even cultural context. It conveys the practice, not the value it brings.

Ok, let’s rename it!

It could help somewhat (if you can now re-educate thousands of developers worldwide –they probably won’t let go of what they’ve mastered so quickly). But I don’t believe just changing the name will change behavior.

When I explain unit testing, I start at the pain: bugs. Stupid bugz. Returning bugs. Let me clue you in – developers are creatures of ego. We care about what we do, and any bug found is a dent in our armor. Bugs drive us nuts. And we’re ready to invest some time (minimum, if possible) in making sure our face-time with QA is limited.

(QA people – I love you, you know that. Don’t take it the wrong way, but in the development story, we shoot the messenger, the one who found the bug).

So when you come to persuade, use the right context and language and talk to the heart. You’ll get better acceptance, and probably take away the effect of the name.

4 comments on “Unit Testing Is Spooky!”

  1. Anonymous Reply

    Unit testing makes sense in Java, where it originated, and for many other compiled languages. It doesn’t so much for scripting languages. The required syntactic salt and testing methodology is overkill for e.g. mainly procedural code. Hence people eschew it. There are simpler testing methods, but nobody knows about it, because unit testing is an attention whore. It has its deserved place in enterprisey code, but should not be advertised as the nonplusultra. And I assume that contributes to the terms ‘spookyness’ a bit. Not sure if a more descriptive name would ->assertHelp.

  2. Gil Zilberfeld Reply

    Unit testing is not suitable depending on the language. Tooling and the ability to write tests differ between the languages.

    And spookyness can be increased and decreased by your choice of language and tool.

    But if a developer doesn’t even know what a unit test is, and the first thing that pops in her mind is “That’s more work for me”, she’s already spooked.

    Knowledge dismisses fear (and spookyness). But we need to understand that the first step (the name?) should already decrease objection on the receiving side.

  3. Jerry Durant Reply

    I guess my first reaction to a developer who is unfamiliar with unit testing, or for that matter any testing, is whether they are a developer or simply a code smith. Now again, terminology aside, the principals of engineering are well established and this includes more than coding, it involves analysis, v&v and design. This what sort of proof can be provide other than possible a clean compile or open functional signs of working? Permitting free passage on words of assurance, devoid of a demo that is a form of testing is suicidal at best.

    • Gil Zilberfeld Reply

      Jerry, sometimes the only proof needed is that you pushed your code in. If that’s what the team lead or R&D manager’s view, that’s what people learn to do. It’s suicidal for the business, but, hey, the devs are cranking code out.

Leave A Reply

Your email address will not be published. Required fields are marked *