uli at gnufix
May 17, 2012, 5:22 AM
Post #2 of 4
On Wed, 16 May 2012 03:40:17 -0500 Jeff Rush wrote:
> Are many folks using zope.pytest? We're looking into it but, for such a
> small amount of code, are finding it a bit odd and seemingly broken.
No, I don't think many folks are using it right now. zope.pytest was a
quick shot to check out, what is possible with py.test in Zope
environments and to give folks used to py.test an easier entrance to the
Zope world. However, we got stuck a bit with some principal problems
> Breaking down the basic creation of an application object, here is what
> the code does, with indentation to show what a method call performs:
> db = setup_db()
> storage = DemoStorage(name)
> db = DB(storage, database_name=name)
> db.setActivityMonitor( ZODB.ActivityMonitor.ActivityMonitor() )
> notify( zope.processlifetime.DatabaseOpened(db) )
> return db
> connection = setup_connection(db)
> return db.open()
> connection.root()[ZopePublication.root_name]['test'] = site_root
> My issues are:
> 1) the DatabaseOpened event is sent out _before_ the ZODB is actually
> opened, making it hard to use handlers to initialize a test layout in
> the ZODB.
The main idea of zope.pytest is to provide a ready-to-use db without
much setup stuff included from the users side. It's for users that want
some plain ZODB with some `site` and don't care much where it comes from
or how it looks like. If you want your very own and special setup or
test layout, you yet have to write the setup/teardown code down yourself.
> 2) there are no other events emitted, such as after root is initialized.
Please see above.
I nevertheless understand that your use-case is common. zope.pytest
could/should provide additional helpers to create such customized test
> 3) there is a key lookup of "ZopePublication.root_name" inside
> connection.root() before any code has _set_ such a key, raising a key
> lookup exception in my basic evaluation pgm.
I think this is normally done by zope.app.appsetup, via a subscriber.
Never had this problem, so I cannot tell much.
> 4) there are no examples of tests that use the 'test' subscript, and I'm
> puzzled by the extra level of indirection instead of just using
> ZopePublication.root_name in test_XXX functions.
Well, that's a matter of abstraction. We wanted to put away DB setup
stuff from the user. You simply should not have to care for things like
`root_name`. This approach, of course, finds it limits when you want DBs
already filled with data, etc.
> 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
> I've googled to find others using zope.pytest, to see examples of
> correct usage in a ZODB-based testing environment, without luck.
The main problem why we got stuck is test separation.
Especially the setup and teardown of ZCA registrations, which should
happen before and after each single test and might be different for
certain groups of tests. So we looked for some replacement of the way
zope.testing layers are doing it, but still could not find anything
similar in py.test which makes it hard to use already available
techniques (for instance provided by plone.testing) as there seems to be
no hook in py.test to trigger this stuff at the right point in time.
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.
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.