[ENH][TEST] ClassBuilder format tests

Julian Fitzell julian at beta4.com
Wed Jan 7 19:07:58 UTC 2004


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.

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

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.

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.

Julian




More information about the Squeak-dev mailing list