[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.
Yes
> 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.
Stef
>
> Julian
>
>
More information about the Squeak-dev
mailing list
|