[Zope-dev] How to test changes to ZTK packages?

[Christian Theune]

Hi,

On 07/01/2009 11:12 AM, Jim Fulton wrote:
>
>> [...]
>>
>> You can specify include and exclude options; the default is to
>> include a
>> list of zope.* packages that we pulled out of thin air at the sprint,
>> it'd probably be better to use the KGS as a default instead -- but
>> that
>> would duplicate even more zope.release functionality.
>
> Where is this list? In the recipe?

The recipe takes two arguments:

- a list of regular expressions to describe packages that should be
   included
- a list of regular expressions to describe packages that should be
   excluded

There is currently a builtin list for each of them that gets appended to 
the ones you specify when using the recipe in your buildout.

>> I think it would be useful to standardize on *one* compatibility
>> testing
>> method for the ZTK (and then document it).
>
> Yes.
>
>> My instinct would be to separate KGS handling from tarball creation
>> from
>> testing, that is, remove the test-business from zope.release and use
>> the
>> compattest recipe instead. (Alternatively, retire compattest and have
>> zope.release gain the ability to use trunks so it could be used for
>> continuous integration purposes as well -- but that doesn't feel quite
>> right, to be honest)
>>
>> Thoughts?
>
>
> I agree we need one way to do this. I think the KGS concept is right.
> I think there should be a known good configuration of packages and a
> way to evolve it.  The configuration should be changed only after
> testing changes.  The configuration needs to include Python versions
> that it is tested with.  Beyond that, I don't care what the process is
> as long as it is documented.

The compattest is intended to check the trunks of packages located in 
one repository like svn.zope.org against the development version of the 
package you're working on so you can see whether your changes will cause 
others that depend on you to break.

I think it's one of the issues we need to solve in our process and it 
was actually very valuable when doing the large dependency refactoring 
at the sprint.

If you have a multi-core machine, you can also ask it to run the various 
test runners in parallel. I was able to execute the 100+ package tests 
in less than 10 minutes on an 8-core machine.

Christian

-- 
Christian Theune · ct at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development