[ENH][TEST] ClassBuilder format tests

ducasse ducasse at iam.unibe.ch
Wed Jan 7 18:52:15 UTC 2004

On 7 janv. 04, at 19:09, Julian Fitzell wrote:

> ducasse wrote:
>> On 7 janv. 04, at 08:12, Julian Fitzell wrote:
>>> I dunno - the majority of people are not going to want those tests 
>>> most of the time.  The only people who really need them are people 
>>> hacking on the core image itself, not users of it.
>> Do you think that tests on integers, strings, collections are really 
>> useless?
> No, *I* think they're very useful.  But I don't think Joe Schmoe 
> application user, or even Joe Schmoe application developer cares 99% 
> of the time.
>>> I don't feel that strongly, but every time something like this comes 
>>> up it seems we eventually agree we're trying to *limit* the number 
>>> of things being pushed out the update stream.  It's only a few 
>>> clicks to install the tests and it's easily done for those who want 
>>> them.  Those who don't are never going to run them anyway, so we 
>>> don't gain anything by forcing them out there.
>> I disagree,  consider tests as documentation. You do not want a 
>> newbie to load a test package. It should be there. Tests are cheap in 
>> space, easy to remove and we can remove these is less that few 
>> clicks.
>> There are so few people taking care of tests that we should make 
>> their life easy. Because you see if the test would be in the image
>> then boris would have just been able to publish in three minutes a 
>> new test. And not have to load the testpackage.....
>> Now I have to check if this is a method or a new test case....boring 
>> boring boring.
>> I spent enough time on that.
> We're back to mixing up the issues again.  I don't object to tests 
> being in the image; I have a problem with them being in the *update 
> stream*. Publishing package updates in the update stream is a horribly 
> ugly and confusing mix of two paradigms.
> The newest version of the test package is always on squeakmap - this 
> means that the one in the update stream will frequently be out of 
> date.  This is confusing.  If we think core *developers* need an 
> easier way to load the tests than choosing it from list of packages 
> then we should create an easier way for them to do so.  Putting them 
> in the update stream, imo, just confuses things.
> 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.

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

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.

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


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

> Julian

More information about the Squeak-dev mailing list