[Zope-dev] test setup layer sorting
zope/testing/testrunner/runner.py's order_by_bases() function orders layers by inheritance, basically. So if you've got a FunctionalTestLayer that inherits from some BasicTestLayer, the tests that use the basic test layer will be executed before the functional test layer ones. If there's no inheritance, the layers are sorted by name. Quite sane. Problem: I use grok. Which does some magic that probably throws off the code coverage reports. Quite some code appears untested, even though I *do* test it. The problem disappears if just import the python module first in some basic test before the grokking happened. I use z3c.testsetup: - My basic doctests end up on the zope.testing.testrunner.layer.UnitTests layer. - My functional doctests on the z3c.testsetup.functional.layer.DefaultZCMLLayer layer which inherits from zope.app.testing's ZCMLLayer. - zope.app.testing's ZCMLLayer does not inherit from anything, so also not from zope.testing's unittest layer. - 'zope' is alphabetically behind 'z3c.testsetup', so the functional layer is sorted in front of the basic unittest one. - So my grokked code appears untested. What's the best solution? Should zope.app.testing's ZCMLLayer inherit from zope.testing's UnitTests layer? Should z3c.testsetup do some inheriting of its own? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On Mon, Jul 13, 2009 at 09:27:54AM +, Reinout van Rees wrote: zope/testing/testrunner/runner.py's order_by_bases() function orders layers by inheritance, basically. So if you've got a FunctionalTestLayer that inherits from some BasicTestLayer, the tests that use the basic test layer will be executed before the functional test layer ones. If there's no inheritance, the layers are sorted by name. Quite sane. Problem: I use grok. Which does some magic that probably throws off the code coverage reports. Quite some code appears untested, even though I *do* test it. The problem disappears if just import the python module first in some basic test before the grokking happened. I use z3c.testsetup: - My basic doctests end up on the zope.testing.testrunner.layer.UnitTests layer. - My functional doctests on the z3c.testsetup.functional.layer.DefaultZCMLLayer layer which inherits from zope.app.testing's ZCMLLayer. - zope.app.testing's ZCMLLayer does not inherit from anything, so also not from zope.testing's unittest layer. - 'zope' is alphabetically behind 'z3c.testsetup', so the functional layer is sorted in front of the basic unittest one. - So my grokked code appears untested. What's the best solution? Whatever grok does that interferes with coverage should be fixed. Should zope.app.testing's ZCMLLayer inherit from zope.testing's UnitTests layer? Personally I would much prefer for the unit test layer to be sorted first. It is already treated specially by zope.testing; I see no harm in hardcoding its sort order. Should z3c.testsetup do some inheriting of its own? That to me sounds like the wrong place to fix this. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form: data manager forPersistentDict/PersistentMapping
Am 12.07.2009 um 01:46 schrieb Roger Ineichen: Hi Michael Betreff: [Zope-dev] z3c.form: data manager forPersistentDict/PersistentMapping Hello, z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one: 1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.) I think this is the right solution I think so, too, but I was not sure. because there are many places in zope which do not work if a PeristentDict or PeristentList is given instead of a simple dict or list type. I'm not sure but I guess not even the zope.schema validation implementation does this part correct for list or dict fields. This is another problem. z3c.form.datamanager.DictionaryField sets the value directly on the dict, so I'd like to use a PersistentMapping instead of a dict to get the persistency stuff for free. I use the PersistentMapping to store the schema values, as I need to keep them in the session. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form: data manager for PersistentDict/PersistentMapping
Am 11.07.2009 um 17:43 schrieb Michael Howitz: Hello, z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one: 1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.) 2.) Register DictionaryField for zope.interface.common.mapping.IMapping. This might have a problem as neither UserDict nor PersistentDict/PersistentMapping seem to provide this interface. (Why?) Replying to myself, as I saw on the z3c.form trunk that DictionaryField already allows providers of zope.interface.common.mapping.IMapping additionally to dict instances as the storage object. The existing solution uses the second of my possibilities, but this is not the one which I'd like to prefer, as it does not work with PersistentMapping out of the box. The idea behind this change on the trunk seems to be: to allow SessionPkgData as storage. I currently do not use it directly but use a PersistentMapping inside SessionPkgData. But maybe this is a sufficient solution for now. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Creating new five.* package
We've started a new package, five.hashedresource, that is supposed to integrate z3c.hashedresource into Zope2. Just to make sure not to step on someone's toes: is it OK to just create such a package in that namespace? -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Creating new five.* package
On Mon, Jul 13, 2009 at 1:28 PM, Thomas Lotzetho...@thomas-lotze.de wrote: We've started a new package, five.hashedresource, that is supposed to integrate z3c.hashedresource into Zope2. Just to make sure not to step on someone's toes: is it OK to just create such a package in that namespace? +1, the namespace is pretty clear for anything that integrates newer zope.* stuff into Zope2. Even though, the original 2+3 = 5 equation doesn't work anymore with 2+ZTK = ?, I think the name is well established. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On 2009-07-13, Marius Gedminas mar...@gedmin.as wrote: Whatever grok does that interferes with coverage should be fixed. I did some more debugging. In the end it boils down to this: With z3c.testsetup, you can specify a zcml file at the top of your test file. z3c.testsetup creates a ZCMLLayer with that zcml file. I my test files, I had two separate zcml files (one registered a bit more than the other). So I ended up with two separate ZCMLLayer subclasses. And both did some grokking. So apparently the teardown of a ZCMLLayer subclass when going from one to the next isn't that clean. There *is* a warning in zope.testing that teardown isn't fully supported. Personally, I'm not sure where the exact problem is. Grok does decorator-like wrapping (should not throw off the coverage testing) and plain component architecture registration (should not throw off the coverage testing either). Tearing down a component architecture layer? Code coverage problems don't seem too common. Probably an interaction between two problems. How I solved it: just use one zcml layer in z3c.testsetup and do some extra grokking in the test itself instead of in the second zcml file. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On Mon, Jul 13, 2009 at 5:55 AM, Marius Gedminasmar...@gedmin.as wrote: Personally I would much prefer for the unit test layer to be sorted first. It is already treated specially by zope.testing; I see no harm in hardcoding its sort order. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form: data manager for PersistentDict/PersistentMapping
On Saturday 11 July 2009, Michael Howitz wrote: z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one: 1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.) 2.) Register DictionaryField for zope.interface.common.mapping.IMapping. This might have a problem as neither UserDict nor PersistentDict/PersistentMapping seem to provide this interface. (Why?) I looked at this recently and the reason is that for containers we did not usually want the dictionary field data manager, because we usually want the regular instance based one. I am okay to add PersistentDict and PersistentMapping to the list. I am already feeling unsure about UserDict, because people might want the instance version instead. It is better to register the adapter for the specific cases of your application. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On Mon, Jul 13, 2009 at 12:27:50PM +, Reinout van Rees wrote: On 2009-07-13, Marius Gedminas mar...@gedmin.as wrote: Whatever grok does that interferes with coverage should be fixed. I did some more debugging. In the end it boils down to this: With z3c.testsetup, you can specify a zcml file at the top of your test file. z3c.testsetup creates a ZCMLLayer with that zcml file. I my test files, I had two separate zcml files (one registered a bit more than the other). So I ended up with two separate ZCMLLayer subclasses. And both did some grokking. So apparently the teardown of a ZCMLLayer subclass when going from one to the next isn't that clean. There *is* a warning in zope.testing that teardown isn't fully supported. Ah, that one. zope.testing supports test layers that muck up the global state irrepairably (by letting the layer's tearDown method raise NotImplementedError) and continues running the subsequent test layers in a fresh and squeaky-clean subprocess. Unfortunately, a separate process means separate coverage data tracking, and currently zope.testing doesn't support merging coverage data from several processes. Fortunately, the NotImplementedError in ZCMLLayer's tearDown is just a precaution, 99% of the time it is sufficient to run CleanUp.tearDown to get the global state restored to its pristine condition. You can indicate that it is safe by passing allow_teardown=True to ZCMLLayer's constructor. As a result: * the tests will run marginally faster (no subprocess overhead) * you will be able to use pdb in your tests (zope.testing disables pdb in a subprocess since it wants exclusive control over stdout) * you will be able to get accurate coverage tracing. Now, how you can convince z3c.testsetup to pass allow_teardown=True to the ZCMLLayer it constructs, I don't know. I've never used z3c.testsetup (although it sounds like an interesting library and I should check it out some day). ZCMLLayer's allow_teardown=True badly needs more publicity. Or maybe a ruthless dictator, decreeing that it shall be on by default from some near-future date. How I solved it: just use one zcml layer in z3c.testsetup and do some extra grokking in the test itself instead of in the second zcml file. That will work until you decide to introduce a new layer. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] test setup layer sorting
On Mon, Jul 13, 2009 at 3:36 PM, Marius Gedminasmar...@gedmin.as wrote: Fortunately, the NotImplementedError in ZCMLLayer's tearDown is just a precaution, 99% of the time it is sufficient to run CleanUp.tearDown to get the global state restored to its pristine condition. Keep in mind that a number of commonly-used ZCML directives stamp interfaces on classes; these aren't cleaned up with the general tear-down. If each layer stamps the same interfaces on the same classes, the only issue is ensuring that unit tests run first. If, however, you have different layers that may apply different sets of interfaces to different classes, you're may be relying on the process boundary as part of the required isolation. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
