On 26 March 2011 14:18, Wolfgang Schnerring <w...@gocept.com> wrote:
> Because, while test layers are nice because they have the above
> properties, I'm not too happy with the current implementation, namely
> the use (or is it abuse? ;-) of __bases__ and __name__, which leads
> very naturally to not-so-helpful implementation patterns. As a
> concrete example, some of the test layers of ZTK packages, most
> notably the successors of zope.app.testing.functional in
> zope.component, zope.app.appsetup, zope.app.wsgi, are implemented
> right now in a way that does not have properties 2+3.
> The most straightforward way to improve that situation would be to use
> plone.testing, since that provides a layer implementation that is both
> sane and easy to use, and has all the nice properties. (Maybe even
> fold some of it into zope.testrunner itself.)
I'd be happy to move layer.py from plone.testing to zope.testrunner for sure.
> But then I realized, that's a major undertaking, so we better think
> about what the actual goals are before changing lots of stuff. And
> then I heard people expressing interest in other test runners.
> (py.test and nose seem to be the biggest players, stdlib's
> unittest/unittest2 seems to be woefully behind in terms of test
> selection and other features like coverage or debugging. I for one
> happen to like zope.testrunner, but if there's a good alternative, why
> not combine our efforts?)
> I also found that it is rather hard to explain how to use test layers
> in a way so you actually get the above properties, so I started
> wondering whether there was a cleaner way to get them.
Personally, I rely a lot on the layer mechanism and would not want to lose it.
> So I guess I have three questions:
> 1. (The starting point:) How can we improve the test infrastructure
> situation of the ZTK packages?
I'd say having more reusable test layers would help.
> 2. (The main thing:) Are test layers, both the concept and the
> implementation as epitomized by plone.testing, the way to go or is
> there a cleaner alternative?
When we looked at how to improve Plone's testing story, we couldn't
find anything better. One thing I would like is a better way to
support "python setup.py test".
> 3. (But only tangentially, I don't want to sidetrack the discussion at
> hand nor start a flamewar:) Is there a compelling alternative to
> zope.testrunner that would make it worthwile to think about either
> generalizing the fixture support or even migrating away from
It's a good question to ask, though I think this would be a really big
undertaking for maybe only marginal gain (if any).
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -