On 3 févr. 04, at 07:32, Doug Way wrote:

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

No we discussed a lot about that and you summarize well the situation 
of today 3 february 2004.
Now if people want to help go ahead there are plenty of room for 
improvements so that we can split and still do not
lose too much in the process (for tests they can be removed from the 
image in less than 10 minutes)

I think that #4 is reasonable to do now and will become obsolete as 
soon as tool support, dependency...improve.

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