[ENH][TEST] ClassBuilder format tests
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
> 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
>> 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
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
> 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.
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.
More information about the Squeak-dev