Where did you learn to unit test? How did you learn?

Russ Salsbury rcs at russellsalsbury.com
Wed Apr 30 20:49:28 CEST 2003

blunck at gst.com (Christopher Blunck) wrote in message news:<1147e466.0304290638.287687f6 at posting.google.com>...
> What advice can you offer on spreading the testing bug around?  

It's very much a cultural issue.  First and foremost you have to have
to use it yourself.  If you are an indifferent user, you can't
convince others to use it.  Be consistent, even for trivial cases.

It's much easier to spread the word if your manager supports you.  A
good manager can encourage others to use unit testing.  S/he can even
make it a requirement of checking in code.  (Unit tests are much more
effective in ensuring quality than are code reviews.)  OTOH, if your
manager is not well respected by your peers, he can actually inhibit
the process.

If you are a manager, find an evangilist in your group.  Get some
successes before you impose the full rigor on everyone.  You don't
need a revolt at the very beginning.  That said, requiring tests for
checkin should be done from the beginning.

Another possible ally is the QA manager, who could enforce the
requirement for tests before checkin.  S/he should also include unit
tests in the regression/acceptance tests.

I found that rigorous unit testing can be difficult to introduce into
a large existing piece of code, esp. if there are multiple developers
of varying degreees of enthusiasm.  In spite of that, I have found
that it is most productive, when inheriting a big chunk of code, to
take the time, even a month or more, to refactor it, write unit tests,
and put in strategic traces and object dumps.  It more than pays off
by the time release comes around.
> What practices did you follow?  

I recruited an eager and talented QA tester who wanted to move into
development to set up the JUnit framework and become the first

> Did you beat people over the head with it until they wised up?  

A developer may be able to do that, but a manager usually fails at it.
 There are too many ways for the disgruntled to sabotage it, esp. in
larger organizations.
> Were you softer in your approach?  

Apparently not soft enough, because I got canned a few months later.
Actually, it worked in my group, but I was chartered to improve the
development practices of the entire company and when the President was
replaced and the VP of Engineering and the Chief Architect left, the
disgruntled had their way.  Pythonistas do not always triumph. ;-)
> What were the long term implications?

The company went bankrupt a few months later. :-)

The long term implications:  no matter what happens you are a better
programmer if you do rigorous automated(!) unit testing.  Your company
produces a better product and has a better chance of long term success
if everyone does.
-- Russ

More information about the Python-list mailing list