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

[Russ Salsbury]

blunck at gst.com (Christopher Blunck) wrote in message news:<1147e466.0304301815.75ddb614 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?
>
I haven't had much of that.  A lot of my work has been as a
consultant, so if I got resistance, I stopped preaching, but still
continued to use best practices.  Technical organizations are often
resistant to changes in methodology. Sometimes you can make chages by
proposing it.  Sometimes you just have to do it. As Grace Hopper said,
"It is better to ask for forgiveness than to ask for permission."
 
> 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.)
>
Just do it the right way.  I have had a manager say you can't
implement it that way (that's OK; he pays the bills), but I have never
had anyone say you can't unit test.  OK, I have had people say. "We
don't have time for testing.", but nobody has actually stopped me.

85% of all software projects fail.  I guess those are the ones where
the programmers are not rational or are afraid of failure or are
afraid to go against the tide.  I have seen a lot of cases where
managers refuse to see reality.  If the programmers quietly do it the
right way, the project could succeed.  If they follow along the wrong
way, it will certainly fail.  A colleague once told me that an
organization can succeed even if every other layer is incompetent, but
it will fail if two laysers of incompetence are next to each other.  I
would say that if you find yourself in that situation, it's time to
leave.

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

I had it easy, because I knew him and had seen his work.  It wasn't
the typical interview situation.  I haven't found the surefire
questions and I suspect that they don't exist.  For a long time I
worked with a woman who was not the technical heavyweight in the
group, but who had an unerring ability to judge character and
suitibility.  I gave her veto power over hiring.  I know that it was a
personal copout, but it worked.  I also learned from her that good
organization and technical consistency often beat out brilliance.
 
> 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.  :)

I think Pythonistas triumph in the long run because they have an
interst in programming as an art and they choose Python out of a sense
of aesthetics.  Certainly if it were a purely economic (as in
marketability of skills) we would all be programming in perl.  When I
program in Python I feel a pride in my craft that goes far beyond
cranking out a lot of code quickly.
 
> 
> > > 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.  ;-)

Actually that was a bit of hyperbole.  The company went through a lot
of turmoil and lost its way. It had switched product directions
several times over a two year span.  It got a new president and
shortly afterwards the VP of Engineering (my boss), the CTO, the Chief
Architect (my ally in unit testing and other reforms) and the product
guru all left, to be replaced by the president's friends and her son. 
For all practical purposes, marketing ended up running engineering. 
Needless to say, the problems with development methodology were only
symptomatic.

However, your point about reckless building is well taken.  When
marketing feature lists and engineering kludges drive development, you
end up with an unstable product and missed deadlines.  When you miss
deadlines you miss the market, and if you are a small company, you're
dead.  And if you don't know what market you're after or what business
model you're using, you're dead beyond any hope of resurection. 
Repeat this several thousand times and you have the .com crash and our
current depression. (Recession seems too mild.)

> 
> 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...
>
Remember Philip Crosby's book "Quality is Free?"  His point was that
the cost savings paid for the cost of quality improvement.  The same
is true of unit testing and other Agile Programming disciplines: "Unit
Testing is Free."  In fact is's better than free; it's a tremendous
competitive advantage, for both the programmer and the company.

-- Russ