Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

Puzzle re zope.pytest

 

 

Zope dev RSS feed   Index | Next | Previous | View Threaded


jrush at taupro

May 16, 2012, 1:40 AM

Post #1 of 4 (286 views)
Permalink
Puzzle re zope.pytest

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.

Breaking down the basic creation of an application object, here is what
the code does, with indentation to show what a method call performs:

create_app()
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.

2) there are no other events emitted, such as after root is initialized.

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.

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.

5) the unit tests for zope.pytest itself are failing with:
> from zope.interface.interfaces import ComponentLookupError
E ImportError: cannot import name ComponentLookupError

I've googled to find others using zope.pytest, to see examples of
correct usage in a ZODB-based testing environment, without luck.

-Jeff
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


uli at gnufix

May 17, 2012, 5:22 AM

Post #2 of 4 (267 views)
Permalink
Re: Puzzle re zope.pytest [In reply to]

Hi Jeff,

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
(see below).

> Breaking down the basic creation of an application object, here is what
> the code does, with indentation to show what a method call performs:
>
> create_app()
> 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
layouts.

> 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
version.

> 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.

Best regards,

--
Uli
Attachments: signature.asc (0.19 KB)


baiju.m.mail at gmail

May 17, 2012, 5:48 AM

Post #3 of 4 (271 views)
Permalink
Re: Puzzle re zope.pytest [In reply to]

On Thu, May 17, 2012 at 5:52 PM, Uli Fouquet <uli [at] gnufix> wrote:
[...snip...]
> 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.

Something like this should work:

def pytest_funcarg__app(request):
"""Create app funcarg"""
return request.cached_setup(
setup=_get_app, #this should return an app object
teardown=_release_app, #destroy things here
scope='function')

def test_something(app):
pass

Regards,
Baiju M
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


jrush at taupro

May 19, 2012, 10:59 PM

Post #4 of 4 (255 views)
Permalink
Re: Puzzle re zope.pytest [In reply to]

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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

Zope dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.