Hi, On 04/17/2010 06:34 AM, Martin Aspeli wrote: > Hi Lennart& co, > > On 17 April 2010 02:38, Lennart Regebro<rege...@gmail.com> wrote: >> On Fri, Apr 16, 2010 at 19:53, Jonathan Lange<j...@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 · c...@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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
