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
> 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
** No cross posts or HTML encoding! **
(Related lists -