* Jim Fulton <j...@zope.com> [2009-08-02 18:34]:
> 2. Some of the tests only pass if run separately, due to test
> interactions. Presumably, this means that other tests aren't cleaning
> up after themselves. I think we need a standard automated way to run
> each package's tests separately. I think some folks are working on
I've just released z3c.recipe.compattest-0.6, which can now populate the
list of packages to run test for from a buildout section, which makes it
easy to test against a KGS. So, if you're developing zope.foo, you can
set up your buildout.cfg like this:
develop = .
parts = <whatever else you need> compat
extends = http://url/to/kgs/versions.cfg
# assuming said versions.cfg uses a section called [versions]:
versions = versions
# use development version of our package
recipe = z3c.recipe.compattest
and then run bin/test-compat to run the tests of each package in
versions against the development version of zope.foo (in a separate process).
> So this means that if someone modifies a package that is in the KGS,
> they need to run the KGS tests before checking in.
After we reach a consensus on how to do it (I'm in favor of the way
outlined above, of course ;-), I'd like to add a step-by-step
walkthrough of the day-to-day development of a package somewhere below
<http://docs.zope.org/zopetoolkit/process/index.html>, which would
include a description of how to run KGS tests.
Regarding the KGS, I have a question: Where is the current KGS and how
do we update it?
By "where is" I mean the location of the versions.cfg,
by "current" I mean the "trunk", the version currently in development,
the version where we probably want to bump the version number of a
package as soon as a version is released,
and by "update" I mean that I'd like this operation to involve no manual
interaction other than committing the new version number to SVN.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -