phuu.. got locking working.. strongly suggest that module documentation should also contain hints about how to configure the module and what other special modules have to be installed to make it work (in this case zope.app.keyreference)

J1m: Would you object to the new test runner supporting something similar to my resources? A resource as I think of it would be identical to the existing layers, so the change would be a test could specify multiple layers instead of just one.

J1m: ok. The other issue that got brought up in discussions with my cow orkers was that the seperation of powers seems wrong. One idea seems to be that the testrunner should assemble the list of tests, stuffing them in a test suite and then calls testsuite.run(). The test cases inherit from a common base class which contains the intelligence to setup the layers if they are not already setup, and to tear down the layers if they are not needed

But I think that is a longer term thing, and you might not agree. There are extra tricks needed to keep functionality, such as the TestSuite needing to fork in order to restart the tests in a new process.

this might not be exactly relevant, but recently we started experimenting with a distributed test runner (rsync source into N machines, use ssh + python on the other end to run the test runner in slave mode; report results as they come locally)

Yes - that was how I was thinking of doing it. It could have been done using a helper that generates the class on the fly, except that we then couldn't run all the tests that 'mix-in' the librarian layer for example.

so list of layers would be better, and the test runner would know that the test doesn't care in which order the layers are setup and can optimize the order appropriately, but in the above spelling the test runner couldn't tell if it was a mix of layers or a 'traditional' layer.