Hi doug

I agree. I was just saying that we as a group should really say that we 
want more tests and following that
we can have test writing session in similar fashion that we have 
harvesting party.
I was saying that we would increase the level of awareness that tests 
are crucial for a more liberal/fast development

Stef

On 18 août 04, at 08:48, Doug Way wrote:

>
> On Saturday, August 14, 2004, at 02:33 AM, stéphane ducasse wrote:
>
>> Hi guys
>>
>> For me any process the people working to make squeak better and safer 
>> is ok. I think that enabling experts to lose less time is important.  
>> After we can always set up some internal or pair coding when fixing 
>> the kernel (I like to have more eyes over my shoulder because I can 
>> simply mess up).
>>
>> Now I would like to add that having a **REAL** campaign for tests is 
>> needed else statements such as
>>> - Anyone committing (broadcasting) to the update stream has to run 
>>> SUnit tests. (which take a couple minutes).
>> makes me really laugh considering the kinds of bugs we could get with 
>> the current tests we have.
>
> Yes, but perhaps the best campaign for getting good tests would be 
> forcing reliance on the tests.  If we went with the proposal of having 
> just one update stream which multiple committers can post to, but they 
> all have to run tests, then the tests would probably start improving 
> more quickly than they are now.  At least, there would probably be 
> some good functional tests added.  (E.g. If [the ability to open a 
> window in MVC] is a typical thing which is broken by bad updates, 
> someone would add a test for opening a window in MVC, and then it 
> would no longer be a problem.)
>
> Running tests before committing updates doesn't seem like too big a 
> deal to me, since I've worked on projects where this was standard 
> procedure.  Especially with Squeak, where one person would probably 
> not post updates very often (maybe once or twice a week at most), 
> running tests doesn't seem like much of a burden.  You can run into 
> some problems, such as the tests growing into a huge suite which take 
> 15 minutes to run, but then this is usually caused by a few tests 
> which are unneccesarily slow, and they can be sped up/fixed.  (E.g. 
> right now the PNG tests take a really long time for some reason... but 
> most typical unit tests are usually very fast.)
>
> - Doug
>
>
>