How to convince devs to do more testing

Why do developers not write more tests? This blog post looks at some reasons why.

In the TDD / XP circles I hang around in, sometimes the question comes up of why isn’t TDD more popular? If the practice helps us write better software at lower cost, surely everyone should be doing it?

So why are these ideas not mainstream?

I think the answer is partly to do with our own bias but also because we are terrible salespeople.

I’ve met untold numbers of people who believe that TDD practitioners are a bunch of grumpy perfectionists who will judge everyone else’s code, try to rewrite everything in their own style, and bring a reign of terror to their team.

No wonder people don’t buy into it!

So how can you be a better salesperson?

You MUST learn to enjoy bad code

I’m a contractor, and I specialise in TDD and XP practices. Since I started contracting, I’ve heard the following twice from two different clients:

“Oh, you won’t like it here. We don’t do TDD. We have some test coverage, but we’ve also got an overly complicated design and a lot of tech debt. I doubt you’ll enjoy it. You won’t be happy here.”

At the time my response was pretty clear:

If I was only happy when I’m working in a well-factored and well-tested codebase, I’d never be happy. Those codebases aren’t just rare, they don’t exist. All code is terrible.

So the first lesson for anyone who enjoys TDD is make peace with the fact that you won’t get to write software your way all the time, and not even most of the time.

Try not to judge other people’s code when you read it

I have to try really hard to not judge other’s people code when I’m reading it. It takes a lot of skill. I think we all probably do it. You’ve got your ego to thank for that.

Since reading other’s people code is an integral part of any professional developer’s job, it’s important to not get too emotionally involved in the task. Otherwise you’ll be frustrated a lot of the time.

Of course you still take pride in your own code. But you should also take pride in your team’s code.

Notice how other people judge you

I’ve thought a lot about these client interactions. On both occasions I remember thinking, why do you have a low opinion of your own software? You should be confident and proud of our creative output, however messy the codebase. Your business is clearly successful. And you probably have the software to thank for that.

But I can see another side to it: this is what they have learned to expect from a TDD / XP consultant.

They read my experience and credentials, and judge me or put me in a box based on their own prior experience with people like me.

That’s a perfectly normal thing to do, and I’m just sorry they had such bad experiences with TDD practitioners in the past.

Stealth testing: don’t tell them about it. Wait for them to ask

Win trust by consistently delivering high-quality software. What I mean is, over a period of many sprints, deliver what you estimated you would, and deliver it bug-free.

You don’t need to focus on how you’re doing it. Just do it and eventually people will start to ask you how you’re doing it. That’s when you tell them.

Teach them by going very, very slowly

Once they’re interested, it’s over to you to show them why your techniques are awesome. Pairing is a great way to do this, but make sure you slow down. If you try to build features at the rate you normally do, you’ll lose them. They have to be able to go at their pace and feel supported.

Perhaps one day, all developers will write tests…