[BUG] Complex equality problem
stéphane ducasse ducasse at iam.unibe.ch 
Wed Feb 8 16:58:32 CET 2006  wrote:


>I suggest that you write SUnit tests to document your
intention and  
>that we can follow what you are doing.

context:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-February/100484.html

Hi stef,
I want to take issue with this suggestion to a new
comer. I know you are trying to improve the quality of
squeak. And I wish that you would think about the
amount of effort you are calling for and who you are
asking to shoulder that effort.

This is like asking someone who comes across a cow
wandering in the wild to find a test that the pastures
gate is closed in the future. Its rather an imposition
on someone who has just done you a favor.

One, using SUnit tests requires learning how. This
learning curve requires time and personal resources to
master.  It is not neccessarily the purpose of the one
who is trying to solve the problem created and left by
another who did not write a SUnit test. Obviously they
did not have time to master Sunit tests as well.

Secondly, stomping on a bug and writing exhaustive
tests to prove the bug remains stomped are two
different efforts.  The second is much more exacting
and to a certain extent made surperfluous by the
eradication of the bug now being tested for.

Thirdly, all you really need is a good interactive “am
I in trouble test.”  Not exhaustive, but a way of
quickly torturing the problem to see if fails. 
Usually the original symptoms of the bug just need to
be recreated and tested for.  This is often an
interactive test and not a SUnit.

Fourthly, looking at the results of SUnit tests is so
boring that some have started writing code to allow
“ignoring” tests that are known to “fail.  That
suggests timely bug fixing is more important.

The proper time to write SUnits is either at the
design stage so you have a way to prove the code works
once you’ve written it. Then the test becomes part of
the documation of the code.

The other proper way to get SUnit tests is get a team
who are trained in the ins and outs of SUnit testing.
Have them work with the bug finders.  If a bug is
found then there will general be a “am I in trouble
test” for it. Have the team take that info and produce
the SUnit.

I realize that producing a team would take
considerable effort on the part of Squeak maintainers.
 Is that effort worth making? If not, putting the
burden on the causal bug finder is not justifiable and
to my sensebilities somewhat obnoxious. 

At the same time any confusions that come up in
turning the finders test into SUnits can be used to
add training documentation to teach SUnit building to
others.

You once warned me that email is a poor way to
communicate. I realize some of my passions have got
into this message.  Please make allowance for that.  I
appreciate that you have spent lots of time and effort
to help squeak grow and that your passion shows in
your suggest for tests.  I hope this discussion gets
us furthur torwards what we both want a better more
capable squeak and a commmunity that has fun using and
developing it.

Yours in service, -- Jerome Peace






__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com