Hi Uli, Thanks for your reply to clarify the history of zope.pytest. On 05/17/2012 07:22 AM, Uli Fouquet wrote:
On Wed, 16 May 2012 03:40:17 -0500 Jeff Rush wrote:
5) the unit tests for zope.pytest itself are failing with:
from zope.interface.interfaces import ComponentLookupError E ImportError: cannot import name ComponentLookupError
You need at least zope.interface 3.8.0. Looks like you're using an older version.
Yes, for backward compatibility with existing packages, we are using Zope 2.12.x which has an older zope.interface in its ZTK.
I admit, though, that I am not too deep into py.test. If you're an experienced py.test user, we might could work out something together and make it more usable. I'd be happy to learn more about py.test from someone more experienced.
No, I'm new to py.test. We had heard good things about it and, a post here on-list (from Jim Fulton) that zope.testrunner should be replaced with a more modern testrunner. I'm not the right one to enhance zope.pytest to better integrate with py.test though.
If, however, you're after a quick, ready-to-use, comprehensive framework for testing Zope applications, you might be better off with other approaches like the regular Zope testrunner and related libs.
Yes, we've been using zope.testrunner here, but some of the developers on the team who are less familiar with Zope don't care for the zope-specific coding in our tests. They had hoped to move us forward with a more general test framework but I guess it can't happen right now. I'm wondering if there is a way to run the improved test APIs of py.test while running it under the zope.testrunner. That way we'd get some of the benefit of py.test, to move away from the various self.assertEqual() calls and to the cleaner way of py.test. Initial investigation says not, that the API benefits of py.test are closely tied to its testrunner. I thought we could create a py.test-specific testsuite() and use the API internally. -Jeff