> ducasse wrote:
>> On 7 janv. 04, at 19:09, Julian Fitzell wrote:
>>> Forget 3 minutes; Boris *should* be able to load the test package in 
>>> 20 seconds, write a test, and then publish it in 20 seconds.  That 
>>> should be doable and we need to make sure it is.  I don't see how 
>>> not loading a package is a prerequisite to making something easy.  
>>> If loading packages is that hard, we have bigger problems we'd 
>>> better solve.
>> This would work if Boris would be the maintainer of the tests 
>> package. But he is not.
>> So if we want to have tests that are a bit consistent then somebody 
>> like an harvester should check that.
>
> Yes, whoever is maintaining the tests needs to "harvest" new tests 
> (whether it uses the same harvesting process or not).  Someone needs 
> to fold individual changes into one package.  But this is true whether 
> we use the update stream or not.
>
>> My point is more important. I think that tests should be visible and 
>> present close to the code they tests:
>>     - for documentation purpose
>>     - for education purpose (I do not know how other cummities do and 
>> I would like to know but from what I
>>     understood Schemers have a lot of tests for their packages, 
>> DrScheme has even a simple but cool widget
>>     to let newbie write tests, I imagine that Python people have the 
>> same attention to tests).
>
> I don't disagree with any of this, which is why I said we should put 
> the tests in the image.
>
>> If we think that tests are as important or even more important than 
>> the behavior they document I do not see why
>> we should treat them differently.
>
> I don't think we are treating them differently.  We are moving towards 
> having all code in packages.  Why wouldn't we do the same thing with 
> the tests?  I realize we haven't succeeded in putting everything into 
> packages yet, but this just means that the tests are getting *Better* 
> treatment, not worse - they're ahead of the game.

But we should not consider tests as in a different package than the 
code they tests. This is especially important since we do not have 
dependencies between packages. Once we will have a good way to express 
dependencies between package we could go for that. in our environment 
here with sotre we separate tests in separate package but this is 
because we do not have SUnit tests,
but tests working more as integration tests, we have a good 
dependencies mechanism (this means that we can easily state to which 
version of a package a tests package is associated).

>>> As best as I can understand, you're trying to encourage average 
>>> developers to write test cases as they go along.  And you feel that 
>>> they are less likely to do so because the test suite isn't in the 
>>> image.
>> Yes
>>>  I agree with this... so let's put the tests in the image.  When we 
>>> build the release image we need to add the test suite along with all 
>>> the other extra packages.  It doesn't need to be in the update 
>>> stream to do this.
>> I agree.
>> For me the problem is that the update stream is handy and consistent. 
>> I really do not see why sending three more classes
>> and changeset would change it.
>
> The update stream *is* handy... for things that have no package update 
> mechanism to update them.  But squeakmap is also handy (at least I 
> find it so) for updating things that are in packages.  If you find it 
> harder to update your test package than to pull in the update stream, 
> then let's find out why and fix that.

May be I do not know. and I do not consider that tests on Integer such 
as the one provided by hans-martin on large integer should be in 
another place that closely related to the large integer class at least 
in the current situation. I used them in my lectures to explain what 
was the different between an implementation and a specification was to 
students and in 5 minute they got it. When the tests were in the image.

> Perhaps it comes down to the difference between declarative versus 
> imperative ways of doing things - I'd rather have version data that we 
> can pull in rather than a stream of commands that doesn't give me any 
> flexibility of what to update when, etc.

I do not know I do not understand what yo want to say exactly. You can 
have a package that strip tests.

Imagine JavaDoc it extracts documentation from comment. so we could run 
a script that remove the comments. This is
the same for tests, they are active, always in sync documentation and 
the closer to the code the better.

> Assuming that the image was shipped with the test package already 
> loaded, what exactly do you find difficult about updating the package 
> from squeakmap?  This isn't a rhetorical question - I'm really trying 
> to figure out exactly what is causing you so much trouble.

I cannot (may be we can but i do not know) update the package from 
within Squeak. Can I publish my code on a server?
We do that daily with store using VisualWorks. One person is 
responsible to produce new release using a merge tools and some version 
conventions. So I'm not against. But right now I do not know if I can 
publish as easily as sending something to the update stream using BFAV. 
At then end this is a question of tool and infrastructure and 
efficiency. Else this is working in ad-hoc fashion.

During alpha I would also like to have the tests in the image because I 
do not want to have to load/unload all the time tests packages. But may 
be doug and marcus prefer something else.

For me the only important point is the idea of increasing the awareness 
of tests in this community because we are not less
clever than other.

Stef
> Julian