Someone emailed me and mentioned that the specific issue of what to do 
with the tests was not really discussed on the list, which is mostly 
true.  So perhaps it was a bit hasty to approve this.

The reviewed changeset below would add the entire contents of the 
BaseImageTests package on SqueakMap to the 3.7alpha update stream.  
This adds 700+ tests to the image.

There are a few things we could do:

1. Keep the base image tests in a separate package on SqueakMap as they 
are now, maintained by Marcus Denker.
2. (variations on #1)  Keep the tests in a separate package on SM, and 
add a special UI shortcut to make it easier to load tests.  Or possibly 
distribute the tests as part of a local cache.
3. Add the package to the update stream as one of those "in-image" 
packages (like SqueakMap itself), which means that the latest master 
copy would still be the package on SqueakMap, but periodically the 
version in the alpha image would be updated to the latest version on 
SqueakMap.
4. Add the contents of the package to the update stream and just 
maintain the code in the image.  The package on SM would become 
obsolete.

I think #4 is probably the best approach.

The main reason is to keep the tests close to the code, so that they 
can serve as a sort of documentation.  In the stable releases, 
beginners will have plenty of example tests to look at.  In the alpha 
releases, the tests will be there for developers to easily use to 
double-check if anything has broken.

Another reason is that as we move toward splitting up the image into 
packages, many of the tests (e.g. AtomMorphTest) will be split off into 
new test packages paired with their corresponding code packages, and 
would no longer maintained in BaseImageTests anyway.  So we're not 
really impeding the splitting up of the image by doing this.  (A ways 
in the future, when we have only a Minimal kernel image left, that 
kernel image would have its own medium-smallish test package, testing 
only the things in the kernel.)

In other words, I think of tests as a somewhat special case... they 
should be split off from the image when the tested code is split off.  
They will be all split off eventually... we'd just do it in a different 
order. :)

I guess I agree with Andreas' sentiment in his earlier message, that we 
don't want to split things up too quickly before the infrastructure is 
there.  It's getting better now with SM2, but we still need an (agreed 
upon) dependency scheme, having BFAV supporting adding 
fixes/enhancements to SM packages, etc.  (Ok, this is only sort-of 
related to the issue of adding tests to the image, but...)

- Doug


Begin forwarded message:

> From: dway at mailcan.com
> Date: Mon Feb 2, 2004  12:56:37 PM America/Detroit
> To: squeak-dev at lists.squeakfoundation.org
> Subject: [ENH] Tests-md ( [er][et] [approved] )
> Reply-To: The general-purpose Squeak developers list 
> <squeak-dev at lists.squeakfoundation.org>
>
>
> Given the discussion on various threads ("community package 
> maintenance"
> etc.), we've decided to incorporate the tests back into the image, so
> that they're close to the code.  So this is approved.
>
> As long as the tests follow the naming conventions (which these do) of
> being in their own class category prefixed with 'Tests-', and have 
> tests
> on specific classes postfixed with 'Test' (e.g. WriteStreamTest), the
> tests should be easy to separate out into packages when the
> corresponding tested code is moved into packages.
>
> - Doug
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <This post brought to you by BFAV2>
>