Hi, On 26 March 2011 14:18, Wolfgang Schnerring <[email protected]> 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 > zope.testrunner? It's a good question to ask, though I think this would be a really big undertaking for maybe only marginal gain (if any). Martin _______________________________________________ Zope-Dev maillist - [email protected] 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 )
