Search This Blog


Monday, March 3, 2008

How Not to Evangelize Unit Testing

Following my posts on How to Evangelize Unit Testing, today I want to write a follow-up on how not to evangelize unit testing.

Doing unit testing is painful for the beginners. They will have a lot of excuses for not doing it, some of them are genuine reasons, some are due of misunderstanding, some are just plain excuses. As an evangelical, the last thing you ever want is to present a wrong case to the skeptics and thus justify their testphobia.

Being someone who is passionate about unit testing in general, and Test Driven Development in particular, I have the experience of preaching the gospel of unit testing to my colleagues. Through trial and errors I have discovered the dos that work and the don'ts that don't. Since I have written about the tricks that work, here I want to write about the pitfalls that you should avoid absolutely as a Unit Testing evangelical.

Here they are, in no particular order.
  1. Read from the Book
  2. Demo toy example, not real life example
  3. Jump straight into TDD
  4. Ask the developers to start doing unit testing straight away
  5. Set test cases quota
  6. Not following up

Read from the Book
The single worst thing you can do when confronted by a skeptic, is to read him a passage from your Sacred Book, be it the Bible, or Koran or Kent Beck's "eXtreme Programming Explained". No one likes to be preached upon. For the non-converts, they want hard evidence, working evidence, not just unproven or unprovable assertions.

It's good to have a unit testing training session for the developers, or a Powerpoint presentation on the benefits of unit testing, but no matter what you present, please don't read from the book during the session, or the developers will fall asleep in no time.

Demo toy example, not real example
The devil, is in the real world, not on the paper. On paper, every methodology works great, even the one that sucks in practice. As an advocate for unit testing, you need to show that unit testing can solve their problems. Showing that unit testing is good for a toy example won't do a thing to convince them that it is equally good for their projects.

If you present a perceived irrelevant ( never mind whether it is really relevant or not) toy example, your audience will ask you what is the relevance of it to his work, and that's if your audience is polite. An indifference or an uninterested audience will just give you smiles and claps and forget you immediately.

Preaching TDD from the start
To be frank, TDD sounds scary..hmm, I mean, revolutionary for the newbie. Writing tests first? This is highly counter-intuitive to the developers! We developers are hired to write code, not to do testing! The mundane testing job is best left for testers, who are naturally a class lower than us the developers.

When I was first exposed to the TDD, I also didn't understand how TDD is a software development methodology, not a testing methodology. I got my eureka moment only when I was so used to unit testing that it seemed painful to not write tests first.

The transition from Plain Old Unit Test to TDD has to be done gradually, seamlessly and unconsciously. Being too pushy about TDD will cause a backlash against even the Plain Old Unit Testing.

Ask the developers to do unit testing straight away.
This is another no-no. After you give a talk on the benefits of unit testing, you ask them to straight away write tests. This won't work.

First, they are not sold yet. Second, even if they are sold, they may not know how to do it, given that they are working on legacy applications. Everyone knows how hard it is to refactor legacy code into something more enlightening. If unit testing is too difficult, or too time consuming to learn, they will not do it.

Set test cases quota.
OK, now the class is over. So everyone should start creating test cases, before this week I want to see 10 cases per developers! So you think by giving them military orders they will scramble to do their jobs? No, they won't.

If you set such a target for the developers, either they will not comply, or they will meet the quota but will not be writing quality test cases. Why? Because it is human nature to game any measurement metric. Gaming the metric that you don't believe in is just too easy for the smart developers.

Not following up
This is the single worst mistake one can make. After the preaching and training, you need to make sure that the developers are actually doing unit tests, or you have to do the tests for them, at least for the start. You have to keep the iron hot all the time. You have to keep the developers, the management and everyone else aware that your company is really, seriously going for unit testing, only then you have some hope in overcoming the resistance.

If you can't keep the momentum high long enough for them to feel that unit testing is inevitable, your efforts to push for unit testing will fail. And it will be considerably harder for you to get them to do unit testing next time.

Do you have any experience in evangelizing unit testing? Please leave a comment here or write your experience on your blog (remember to link me so that I can trace to your blog!) because I would be interested to hear them!


unmaintainable said...

When I joined my current team I was the only one who wrote unit tests. Everybody agreed it was "basically" a good idea but nobody really joined the effort. In fact, I often found my test cases commented out when it was too inconvenient to keep them up to date.

Now, one year later, we're in a situation where it's almost unthinkable *not* to write tests. We were lucky that we got new talented people who enjoy TDD. There was no force in the world that could have convinced some of the old guys because "it takes too much time".

Manuel said...

Nice post :-) In my experience there are two additional points that are very important:

Don't sound like unit tests are all that is required. You'll need functional / integration and acceptance level automated tests, too, and they may be even more important than unit tests when no automated tests exist.

Don't try to get people to run unit tests without addressing the issues that make unit testing hard, like builds that take a day.

Hey, and if you want to start unit testing even your scripts easily, look at my post on an editor independent unittest executor.