Re: [Suggestion] GNUstep-test for quality control (WAS: Re: deferreddeallocation)

[Lars Sonchocky-Helldorf]

On 15.10.2003 20:58:37 Stefan Urbanek wrote:
>Hi,
>
>On 2003-10-15 18:01:13 +0200 Damien Genet <damien.genet@free.fr> wrote:
>
>> Hi,
>>
>>
>> Le mer 15/10/2003 à 17:11, Yen-Ju Chen a écrit :
>>> i fully agree with the sugestion for testing. i think using a
>>> unit testing framework like ocuint 
(http://www.sente.ch/software/ocunit/)
>>> would make things even easier.
>>
>> There is also Greg included with gnustep-guile (but you need to learn
>> some scheme basis then).
>>
>>
>
>Simplier solution: What about lots of users as a 'testing framework and 
quality 
>controll'? Advantage of 'user based testing framework' is that it tests 
>continualy. That 'framework' should also contain users, that were marked 
as 
>'kind of users that gnustep does not need' in a gworskpace thread few 
days ago 
>on this list. More users means more testers and it does not matter what 
kind of 
>users. At this time and state,  gnustep needs any kind of users. More 
eyes see 
>more.
>
>I think, that if at least half of the effort devoted to writing test 
suites (i 
>am not against them) is also devoted to make gnustep more attractive, it 
can 
>also help to remove bugs and have a quality controll. 

That's a circular dependency: less bugs mean more users, more users mean 
less bugs. But the flipside is also true: lots of bugs mean less users, 
less users mean lots of bugs :-(. Currently the situation tends more to 
the latter...

The problem with a "unorganised user based testing" approach is that it 
needs committed, disciplined users to work. That's something you can't 
take for granted. 
My experience tells me instead that far most users simply turn away if 
things don't work out of the box: You even can be thankful if about one 
percent fire their mail client up and send you just complaints, the users 
that are able to give you a qualified bug report you can count with the 
fingers of both hands. 
Another result introduced by the nature of your approach is that you'll 
get many reports for easy bugs you already know, but virtually nobody is 
willing to invest a lot of time to track down a bug which a.) occurs 
irregulary or b.) involves a lot of work. In the end it is like in any 
chaotic multi agent system: the path of least resistance is chosen. The 
already long history of GNUstep is another proof for this.

You make a mistake when you think that the "effort devoted to writing test 
suites" is basically lost time and done just for respectability. 
Let me tell you: it is different. Any amount of time invested in a proper 
test pays off. 
For a long time I also was a opponent of unit testing, I just saw no 
benefit from it, I resisted doing it and left it to the other guys here at 
work. But one day I *had* to do it and it came out to be much less 
complicated then I had feared. In fact I realized that I was so reluctant 
towards it because it was unknown to me. Today I have the habbit to test 
early and often. Unit-testing just helps you to make rapid progress while 
coding. I can tell you that I discovered lots of bugs, even 'thinkos' in 
my code doing testing (often borderline cases where some special treatment 
for certain values was needed) that would have gone undiscovered and would 
have caused bugs hard to track down later on (if you build on a faulty 
foundation you building will most likely be faulty to). 
I wouldn't start a project (even a private) without unit testing today.

>Moreover, gnustep will 
>gain twice by haveing more users - more talkers about gnustep - more 
potential 
>developers. In attractivity also counts: ease of installation, 
comfortable 
>development environment,... It does not have to be perfect at this time.
>
>It may sound a bit naive, but it is not, think about it.
>
>Best regards,
>
>Stefan Urbanek

Greetings, Lars

>
>
>
>
>_______________________________________________
>Discuss-gnustep mailing list
>Discuss-gnustep@gnu.org
>http://mail.gnu.org/mailman/listinfo/discuss-gnustep