Hi, On 04/17/2010 06:34 AM, Martin Aspeli wrote:
Hi Lennart& co,
On 17 April 2010 02:38, Lennart Regebro<regebro@gmail.com> wrote:
On Fri, Apr 16, 2010 at 19:53, Jonathan Lange<jml@mumak.net> wrote:
As the author of one of those other testrunners, I can tell you that if you do this you'll find that your number one biggest problem is getting layers to work.
Ah, right, layers are in zope.testing too. To actually get widespread movement from zope.testing we would have to make some other layer support. Hm...
As you may know, I've been working on plone.testing. This is mainly to make it easier for people working on Plone packages to write "good" tests (and a lot of it is just about patterns, rather than code), but in fact it doesn't depend on Plone (and only soft-depends on Zope 2). I'm certainly hoping to use it for my "plain Zope 3/Toolkit" packages in the future.
plone.testing makes very heavy use of layers. I think layers are a great feature, when done properly, and I haven't seen any better approach. The setUpClass/setUpModule stuff in unittest2 is nice, but doesn't really solve the same problem. For integration testing with something as complex as Zope 2 (or, arguably, the ZODB, various bits of the ZTK, and so on) layers allow "us" the framework authors to make life much easier for those people who are not experts in the framework.
Anyway, a few high level observations:
- In neither plone.testing (apart from its own tests), nor in code that uses it, would I imagine actually depending on zope.testing via an import. We use unittest(2) and doctest from the standard library.
- We do depend on a zope.testing-compatible test runner, in that we expect layers to work. In reality, we depend on zc.recipe.testrunner, though I would *love* to be able to do 'python setup.py test' as well (and have that execute tests with layers). I have no idea how that works or whether it'd be possible.
- The way zope.testing promotes writing layers is actually pretty evil. It overloads the 'class' keyword, essentially, making you spell "base layers" as base classes. This has a few problems:
- If your "base layer" has a testTearDown method, say, and your layer doesn't, the base class version will actually inherit into the child layer. zope.testing will then run the same code twice, once for the base layer and once for the child layer.
- You can't use OOP inheritance to re-use layer conveniences.
- People get quite confused. :)
- You can't have two copies of a layer - all layers are module-level global singletons. This becomes somewhat important when layers manage and expose resources (like database connections).
Minor note: zope.testing *promotes* layers the wrong way and zope.app.testing definitely implements them the wrong way. However, the testrunner itself deals with them in a way that allows you to use them correctly. I think the situation itself could be remedied if the actual layers that are around would be rewritten and a few annoyances (handling of missing methods) straightened out. -- Christian Theune · ct@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