On Sat, Apr 17, 2010 at 06:34, Martin Aspeli <optilude+li...@gmail.com> 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). > > Anyway, based on Ross Patterson's work in collective.testcaselayer, I > think we have something better in plone.testing's layer module.
Aha, interesting. > General info and patterns: > http://svn.plone.org/svn/plone/plone.testing/trunk/README.txt > Layer module: > http://svn.plone.org/svn/plone/plone.testing/trunk/src/plone/testing/layer.py > Layer doctests: > http://svn.plone.org/svn/plone/plone.testing/trunk/src/plone/testing/layer.txt > > If I could have my cake and eat it too, I'd like: > > - A test runner that supports layers > - A test runner that supports the new fixture methods in > unittest2/Python 2.7 - setUpClass and setUpModule > - A test runner that properly reports skipped tests (pretty easy) > - A test runner that supports the above begin run from 'setup.py test' > - A test runner installable via a buildout part just like > zc.recipe.testrunner > > We could quite possibly factor layer.py out of plone.testing and push > it into something else if that was desirable. It's self-contained and > has no dependencies. All this sounds good and not to complicated compared to extracting the testrunner itself. :) Which in turn is less complicated than the work you've already done. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 _______________________________________________ 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 )