Le Mercredi 08 Février 2006 23:02, Peace Jerome a écrit :

Hi Jerome,

> [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.
>
> Hi stef,
>...
> 
> One, using SUnit tests requires learning how. This
> learning curve requires time and personal resources to
> master.

I do not totally agree. SUnit is easy to use and usefull to anyone writing 
some code. So why not learning SUnit ?

> Secondly, stomping on a bug and writing exhaustive
> tests to prove the bug remains stomped are two
> different efforts. ..

A bug finder won't produce exhaustive test, just a little brick usefull for 
non-regression purpose.
SUnit needs not being well structured, uniform and clever. Just a patchwork of 
small independent or overlaping tests will do. So a brick is usefull.

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

you maybe right, but this does not really apply on the small Complex bug found 
here.
This bug was infered using bottom up analysis of code, so writing a small 
SUnit in this case is quite obvious.

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

It seems to me that it is just a good way of organizing things.
You should have a way to categorize tests into
 - non regression tests so far working
 - non yet fixed tests

At least you should replay the non regression test painlessly !
That suggests the SUnit tool need some addition to help categorizing, but if 
guys are writing code, we will all profit by i hope.

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

Note that simple coverage tools would not help on the Complex equality bug. 
You would have to be more exhaustive at class level and maybe at value level 
(for each variable...). Something impossible even for well trained i guess.

Some tests at design step, some a posteriori, some small patchwork bricks and 
some independent analysis of code and refactoring, you have to mix all of 
that, i do not think there are only two proper ways.

>
> ... 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
>
Thanks for your great work.