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

[Christopher Blunck]

rcs at russellsalsbury.com (Russ Salsbury) wrote in message news:<3ea624c6.0304301049.52c4027c at posting.google.com>...
> 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.

Yes, but how did you combat the allegation of being "difficult" or
"not a team player".  There are lots of labels that unsympathetic
coworkers can apply to you to subvert your methodology proposals. 
I've found that reputation wins out when it gets down to this level
(My code has unit tests and only has 2 bugs reported so far.  What
about you?  Oh, you don't have unit tests?  Wow.).  What has been your
experience?


> 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.

My manager and I now use the phrase "I believe I hit a vein" when
describing the infectious nature of unit testing.  When you sit down
with a reasonable person (even if they are 20+ years older than you)
and explain the benefits of unit testing, they (assuming they are
rational) usually jump on board (warning:  this is a generalization). 
Having the manager as the catalyst (the person that says 'Thou must
write unit tests') is a great motivator, but rational and level headed
developers take to it quite easily.  What have you done in situations
where you have NOT had rational and level headed developers AND you
lacked the support of your manager and/or team lead?  (This to me
seems like an impossible situation and a change of position seems
required.  But I'm interested in hearing your opinion.)


> 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.

Our QA manager has been influential in coming on board with the unit
testing initiative I've proposed.  But this isn't always the case (QA
engineers sometimes do not recognize the value of unit tests).  I'm
interested in what you've done to overcome that situation.


> > 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
> user/evangelist.

What questions did you ask to determine if the candidate fit your
needs?  I have my own opinions of what questions to ask, but I'm
interested in what you asked since you seem to indicate that you had
some success.


> > 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.

A good point to make.  I'll keep it in mind.


> > 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. ;-)

People of moderate intelligence always triumph over the mediocre 9 -
5'ers.  Our relative importance (like the market) fluctuates, but in
the long haul, our practices are sound.  I've never heard anyone say
that unit testing is a Bad Thing (tm.).  But, I've heard lots of
people explain away *not unit testing* because it was *too difficult*,
*too time consuming*, *not rewarding*, or .. (again) *too difficult*. 
To those I'd say let them sink with their own ship.  While we
pythonistas may go down with the ship, we were the smart souls who
came on board with a life preserver and were able to float to safety
when everyone else drowned and put *yet another* failed project on
their resume.  Don't be deterred - we are in the right, even if the
rest of the jabroni's don't think so.  :)


> > What were the long term implications?
> 
> The company went bankrupt a few months later. :-)

Wow - you are telling me that a company that did not make an
investment in quality software but instead focused on reckless feature
building went under?!  Wasn't that the same thing that happened to
thousands of companies between 1996 and 2001?!  What a surprise. 
Might be worth pointing out.  ;-)


> 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.

And you learn a great deal during unit testing.  Someone on my team
just remarked to me (after underestimating the significance of unit
testing) that the junit tree was as complex and required as much
design as the main code base.  This was flattering to me as it
displayed his recognition that unit testing is as important as regular
development and should be paid the same level of respect.  As you've
pointed out, those that make an investment in regressable unit tests
are the hero's that will be recognized long after they leave the
project.  It's only a shame that they are not there to see the fruits
of their own labor...

-c