testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

classic Classic list List threaded Threaded
10 messages Options
khink khink
Reply | Threaded
Open this post in threaded view
|

testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

When i run tests for individual packages, all pass. When i run multiple
tests (./bin/test), i get an error for a utility lookup
(plone.app.async.interfaces.IAsyncDatabase).

To pin down the problem more, i went into ./bin/test and commented out
all tests but two, f.article and f.discussion. f.article passes without
issue, and then f.discussion fails. (When also uncommenting f.article,
tests pass.)

It seems like in this case, the un-registration for the async mailer in
the second packages isn't picked up at all. The test tries to send mail
and it goes for the async version. I'm guessing i should be able to use
tearDown/tearDownPloneSite (or setUp-) to prevent this, but how?

Some background info: Neither test should use IAsyncDatabase. We use
plone.app.async to send mail asynchronously, which we do (and test) in
another package (f.util.mailer). In all other packages, we use a
different ZCML reistration which tells the test to unregister the async
mailer and use the non-async one, because otherwise writing tests would
be unnecessarily complicated. A typical registration for this
unregistration of async in F.XXX/testing.py:

class FreitagXXXLayer(PloneSandboxLayer):

     def setUpZope(self, app, configurationContext):
        ...
         # in test, use synchronous mailer
         import freitag.util.mailer.tests
         xmlconfig.file('synchronous-mailer.zcml',
freitag.util.mailer.tests,
                        context=configurationContext)

This unregistration of async is done in testing.py of both packages
under scrutiny here (because both send emails).

I've added tearDownPloneSite and tearDown methods to the layer class in
the first package that gets tested (f.article), and see they are being
executed. When i put a pdb in tearDownPloneSite and type
getUtility(IAsyncDatabase)
i get
*** ComponentLookupError: (<InterfaceClass
plone.app.async.interfaces.IAsyncDatabase>, '')
which is okay because we un-registered it.

Question is why doesn't the second package's test not unregister the
async mail-utility, as it does when the test is called with -m "package"?

Kees

[1] Stacktrace for ./bin/test

kees@francis:~/development/zope$ ./bin/test
Running freitag.article.testing.FreitagArticleLayer:Functional tests:
   Set up plone.testing.zca.LayerCleanup in 0.000 seconds.
   Set up plone.testing.z2.Startup in 0.132 seconds.
   Set up plone.app.testing.layers.PloneFixtureCould not install product
plone.app.collection
  Enabling ++resource++plone.app.jquerytools.dateinput.js
Enabling ++resource++plone.app.jquerytools.dateinput.css
Enabling ++resource++plone.app.jquerytools.dateinput.js
Enabling ++resource++plone.app.jquerytools.dateinput.css
in 6.864 seconds.
   Set up freitag.article.testing.FreitagArticleLayer Enabling
++resource++plone.app.jquerytools.dateinput.js
Enabling ++resource++plone.app.jquerytools.dateinput.css
Enabling ++resource++plone.app.jquerytools.dateinput.js
Enabling ++resource++plone.app.jquerytools.dateinput.css
in 8.303 seconds.
   Set up freitag.article.testing.FreitagArticleLayer:Functional in
0.000 seconds.
   Running:
     10/12
(83.3%)/home/kees/.buildout/eggs/Products.PluggableAuthService-1.9.0-py2.7.egg/Products/PluggableAuthService/plugins/ZODBUserManager.py:109:
UnicodeWarning: Unicode equal comparison failed to convert both
arguments to Unicode - interpreting them as being unequal
   userid = self._login_to_userid.get(login)

   Ran 12 tests with 0 failures and 0 errors in 11.998 seconds.
Running freitag.article.testing.FreitagArticleLayer:Integration tests:
   Tear down freitag.article.testing.FreitagArticleLayer:Functional in
0.000 seconds.
   Set up freitag.article.testing.FreitagArticleLayer:Integration in
0.000 seconds.
   Running:

   Ran 21 tests with 0 failures and 0 errors in 1.699 seconds.
Running freitag.discussion.testing.FreitagDiscussionLayer:Integration tests:
   Tear down freitag.article.testing.FreitagArticleLayer:Integration in
0.000 seconds.
   Tear down freitag.article.testing.FreitagArticleLayer in 0.003 seconds.
   Set up freitag.discussion.testing.FreitagDiscussionLayer Enabling
++resource++plone.app.jquerytools.dateinput.js
Enabling ++resource++plone.app.jquerytools.dateinput.css
Enabling ++resource++plone.app.jquerytools.dateinput.js
Enabling ++resource++plone.app.jquerytools.dateinput.css
in 4.092 seconds.
   Set up freitag.discussion.testing.FreitagDiscussionLayer:Integration
in 0.000 seconds.
   Running:
     2/12 (16.7%)

Error in test test_flag_transition
(freitag.discussion.tests.test_freitag_comment_workflow.FreitagCommentWorkflowTest)
Traceback (most recent call last):
   File
"/home/kees/.buildout/eggs/unittest2-0.5.1-py2.7.egg/unittest2/case.py",
line 340, in run
     testMethod()
   File
"/home/kees/development/zope/src/freitag.discussion/freitag/discussion/tests/test_freitag_comment_workflow.py",
line 67, in test_flag_transition
     self.wftool.doActionFor(self.comment, action='flag')
   File
"/home/kees/.buildout/eggs/Products.CMFCore-2.2.7-py2.7.egg/Products/CMFCore/WorkflowTool.py",
line 241, in doActionFor
     wfs, ob, action, wf.doActionFor, (ob, action) + args, kw)
   File
"/home/kees/.buildout/eggs/Products.CMFCore-2.2.7-py2.7.egg/Products/CMFCore/WorkflowTool.py",
line 552, in _invokeWithNotification
     res = func(*args, **kw)
   File
"/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
line 282, in doActionFor
     self._changeStateOf(ob, tdef, kw)
   File
"/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
line 421, in _changeStateOf
     sdef = self._executeTransition(ob, tdef, kwargs)
   File
"/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
line 531, in _executeTransition
     notify(AfterTransitionEvent(ob, self, old_sdef, new_sdef, tdef,
status, kwargs))
   File
"/home/kees/.buildout/eggs/zope.event-3.5.2-py2.7.egg/zope/event/__init__.py",
line 31, in notify
     subscriber(event)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
line 24, in dispatch
     zope.component.subscribers(event, None)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
line 136, in subscribers
     return sitemanager.subscribers(objects, interface)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
line 321, in subscribers
     return self.adapters.subscribers(objects, provided)
   File
"/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
line 585, in subscribers
     subscription(*objects)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
line 32, in objectEventNotify
     zope.component.subscribers((event.object, event), None)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
line 136, in subscribers
     return sitemanager.subscribers(objects, interface)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
line 321, in subscribers
     return self.adapters.subscribers(objects, provided)
   File
"/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
line 585, in subscribers
     subscription(*objects)
   File
"/home/kees/development/zope/src/freitag.discussion/freitag/discussion/handlers.py",
line 59, in notify_comment_reviewer
     notify(MailEvent(mail_message, mail_to, subject=mail_subject))
   File
"/home/kees/.buildout/eggs/zope.event-3.5.2-py2.7.egg/zope/event/__init__.py",
line 31, in notify
     subscriber(event)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
line 24, in dispatch
     zope.component.subscribers(event, None)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
line 136, in subscribers
     return sitemanager.subscribers(objects, interface)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
line 321, in subscribers
     return self.adapters.subscribers(objects, provided)
   File
"/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
line 585, in subscribers
     subscription(*objects)
   File
"/home/kees/development/zope/src/freitag.util.mailer/freitag/util/mailer/handlers.py",
line 183, in handler_asynchronous_send_mail
     queue(job)
   File
"/home/kees/.buildout/eggs/plone.app.async-1.6-py2.7.egg/plone/app/async/utils.py",
line 22, in queue
     queue = service.getQueues()['']
   File
"/home/kees/.buildout/eggs/plone.app.async-1.6-py2.7.egg/plone/app/async/service.py",
line 100, in getQueues
     db = getUtility(IAsyncDatabase)
   File
"/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
line 169, in getUtility
     raise ComponentLookupError(interface, name)
ComponentLookupError: (<InterfaceClass
plone.app.async.interfaces.IAsyncDatabase>, '')


   Ran 12 tests with 0 failures and 1 errors in 0.637 seconds.
Tearing down left over layers:
   Tear down
freitag.discussion.testing.FreitagDiscussionLayer:Integration in 0.000
seconds.
   Tear down freitag.discussion.testing.FreitagDiscussionLayer in 0.005
seconds.
   Tear down plone.app.testing.layers.PloneFixture in 0.045 seconds.
   Tear down plone.testing.z2.Startup in 0.004 seconds.
   Tear down plone.testing.zca.LayerCleanup in 0.001 seconds.
Total: 45 tests, 0 failures, 1 errors in 34.619 seconds.


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
khink khink
Reply | Threaded
Open this post in threaded view
|

Re: testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

I just looked at
http://pypi.python.org/pypi/plone.app.testing/4.2#component-architecture-sandboxing,
and added setUp and tearDown methods, where i call
pop/pushGlobalRegistry(), to the first package.

At the moment it makes the tests for that package fail (url
++add++content.type.defined.in.that.package) but i've a feeling the clue
is here somehere, so that's why i wrote this quick follow-up.

On 11/12/2012 03:51 PM, Kees Hink wrote:

> When i run tests for individual packages, all pass. When i run multiple
> tests (./bin/test), i get an error for a utility lookup
> (plone.app.async.interfaces.IAsyncDatabase).
>
> To pin down the problem more, i went into ./bin/test and commented out
> all tests but two, f.article and f.discussion. f.article passes without
> issue, and then f.discussion fails. (When also uncommenting f.article,
> tests pass.)
>
> It seems like in this case, the un-registration for the async mailer in
> the second packages isn't picked up at all. The test tries to send mail
> and it goes for the async version. I'm guessing i should be able to use
> tearDown/tearDownPloneSite (or setUp-) to prevent this, but how?
>
> Some background info: Neither test should use IAsyncDatabase. We use
> plone.app.async to send mail asynchronously, which we do (and test) in
> another package (f.util.mailer). In all other packages, we use a
> different ZCML reistration which tells the test to unregister the async
> mailer and use the non-async one, because otherwise writing tests would
> be unnecessarily complicated. A typical registration for this
> unregistration of async in F.XXX/testing.py:
>
> class FreitagXXXLayer(PloneSandboxLayer):
>
>       def setUpZope(self, app, configurationContext):
> ...
>           # in test, use synchronous mailer
>           import freitag.util.mailer.tests
>           xmlconfig.file('synchronous-mailer.zcml',
> freitag.util.mailer.tests,
>                          context=configurationContext)
>
> This unregistration of async is done in testing.py of both packages
> under scrutiny here (because both send emails).
>
> I've added tearDownPloneSite and tearDown methods to the layer class in
> the first package that gets tested (f.article), and see they are being
> executed. When i put a pdb in tearDownPloneSite and type
> getUtility(IAsyncDatabase)
> i get
> *** ComponentLookupError: (<InterfaceClass
> plone.app.async.interfaces.IAsyncDatabase>, '')
> which is okay because we un-registered it.
>
> Question is why doesn't the second package's test not unregister the
> async mail-utility, as it does when the test is called with -m "package"?
>
> Kees
>
> [1] Stacktrace for ./bin/test
>
> kees@francis:~/development/zope$ ./bin/test
> Running freitag.article.testing.FreitagArticleLayer:Functional tests:
>     Set up plone.testing.zca.LayerCleanup in 0.000 seconds.
>     Set up plone.testing.z2.Startup in 0.132 seconds.
>     Set up plone.app.testing.layers.PloneFixtureCould not install product
> plone.app.collection
>    Enabling ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> Enabling ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> in 6.864 seconds.
>     Set up freitag.article.testing.FreitagArticleLayer Enabling
> ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> Enabling ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> in 8.303 seconds.
>     Set up freitag.article.testing.FreitagArticleLayer:Functional in
> 0.000 seconds.
>     Running:
>       10/12
> (83.3%)/home/kees/.buildout/eggs/Products.PluggableAuthService-1.9.0-py2.7.egg/Products/PluggableAuthService/plugins/ZODBUserManager.py:109:
> UnicodeWarning: Unicode equal comparison failed to convert both
> arguments to Unicode - interpreting them as being unequal
>     userid = self._login_to_userid.get(login)
>
>     Ran 12 tests with 0 failures and 0 errors in 11.998 seconds.
> Running freitag.article.testing.FreitagArticleLayer:Integration tests:
>     Tear down freitag.article.testing.FreitagArticleLayer:Functional in
> 0.000 seconds.
>     Set up freitag.article.testing.FreitagArticleLayer:Integration in
> 0.000 seconds.
>     Running:
>
>     Ran 21 tests with 0 failures and 0 errors in 1.699 seconds.
> Running freitag.discussion.testing.FreitagDiscussionLayer:Integration tests:
>     Tear down freitag.article.testing.FreitagArticleLayer:Integration in
> 0.000 seconds.
>     Tear down freitag.article.testing.FreitagArticleLayer in 0.003 seconds.
>     Set up freitag.discussion.testing.FreitagDiscussionLayer Enabling
> ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> Enabling ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> in 4.092 seconds.
>     Set up freitag.discussion.testing.FreitagDiscussionLayer:Integration
> in 0.000 seconds.
>     Running:
>       2/12 (16.7%)
>
> Error in test test_flag_transition
> (freitag.discussion.tests.test_freitag_comment_workflow.FreitagCommentWorkflowTest)
> Traceback (most recent call last):
>     File
> "/home/kees/.buildout/eggs/unittest2-0.5.1-py2.7.egg/unittest2/case.py",
> line 340, in run
>       testMethod()
>     File
> "/home/kees/development/zope/src/freitag.discussion/freitag/discussion/tests/test_freitag_comment_workflow.py",
> line 67, in test_flag_transition
>       self.wftool.doActionFor(self.comment, action='flag')
>     File
> "/home/kees/.buildout/eggs/Products.CMFCore-2.2.7-py2.7.egg/Products/CMFCore/WorkflowTool.py",
> line 241, in doActionFor
>       wfs, ob, action, wf.doActionFor, (ob, action) + args, kw)
>     File
> "/home/kees/.buildout/eggs/Products.CMFCore-2.2.7-py2.7.egg/Products/CMFCore/WorkflowTool.py",
> line 552, in _invokeWithNotification
>       res = func(*args, **kw)
>     File
> "/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
> line 282, in doActionFor
>       self._changeStateOf(ob, tdef, kw)
>     File
> "/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
> line 421, in _changeStateOf
>       sdef = self._executeTransition(ob, tdef, kwargs)
>     File
> "/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
> line 531, in _executeTransition
>       notify(AfterTransitionEvent(ob, self, old_sdef, new_sdef, tdef,
> status, kwargs))
>     File
> "/home/kees/.buildout/eggs/zope.event-3.5.2-py2.7.egg/zope/event/__init__.py",
> line 31, in notify
>       subscriber(event)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
> line 24, in dispatch
>       zope.component.subscribers(event, None)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
> line 136, in subscribers
>       return sitemanager.subscribers(objects, interface)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
> line 321, in subscribers
>       return self.adapters.subscribers(objects, provided)
>     File
> "/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
> line 585, in subscribers
>       subscription(*objects)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
> line 32, in objectEventNotify
>       zope.component.subscribers((event.object, event), None)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
> line 136, in subscribers
>       return sitemanager.subscribers(objects, interface)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
> line 321, in subscribers
>       return self.adapters.subscribers(objects, provided)
>     File
> "/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
> line 585, in subscribers
>       subscription(*objects)
>     File
> "/home/kees/development/zope/src/freitag.discussion/freitag/discussion/handlers.py",
> line 59, in notify_comment_reviewer
>       notify(MailEvent(mail_message, mail_to, subject=mail_subject))
>     File
> "/home/kees/.buildout/eggs/zope.event-3.5.2-py2.7.egg/zope/event/__init__.py",
> line 31, in notify
>       subscriber(event)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
> line 24, in dispatch
>       zope.component.subscribers(event, None)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
> line 136, in subscribers
>       return sitemanager.subscribers(objects, interface)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
> line 321, in subscribers
>       return self.adapters.subscribers(objects, provided)
>     File
> "/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
> line 585, in subscribers
>       subscription(*objects)
>     File
> "/home/kees/development/zope/src/freitag.util.mailer/freitag/util/mailer/handlers.py",
> line 183, in handler_asynchronous_send_mail
>       queue(job)
>     File
> "/home/kees/.buildout/eggs/plone.app.async-1.6-py2.7.egg/plone/app/async/utils.py",
> line 22, in queue
>       queue = service.getQueues()['']
>     File
> "/home/kees/.buildout/eggs/plone.app.async-1.6-py2.7.egg/plone/app/async/service.py",
> line 100, in getQueues
>       db = getUtility(IAsyncDatabase)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
> line 169, in getUtility
>       raise ComponentLookupError(interface, name)
> ComponentLookupError: (<InterfaceClass
> plone.app.async.interfaces.IAsyncDatabase>, '')
>
>
>     Ran 12 tests with 0 failures and 1 errors in 0.637 seconds.
> Tearing down left over layers:
>     Tear down
> freitag.discussion.testing.FreitagDiscussionLayer:Integration in 0.000
> seconds.
>     Tear down freitag.discussion.testing.FreitagDiscussionLayer in 0.005
> seconds.
>     Tear down plone.app.testing.layers.PloneFixture in 0.045 seconds.
>     Tear down plone.testing.z2.Startup in 0.004 seconds.
>     Tear down plone.testing.zca.LayerCleanup in 0.001 seconds.
> Total: 45 tests, 0 failures, 1 errors in 34.619 seconds.
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
>


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
Dieter Maurer Dieter Maurer
Reply | Threaded
Open this post in threaded view
|

Re: testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

In reply to this post by khink
Kees Hink <[hidden email]> writes:

> When i run tests for individual packages, all pass. When i run multiple
> tests (./bin/test), i get an error for a utility lookup
> (plone.app.async.interfaces.IAsyncDatabase).

The Zope component architecture is not easy to handle in the
context of test suites. Majors components are global registries
and it is in the nature of things that the use of global objects makes
test isolation more difficult.

Your second message indicates that you are on a good way.
The general approach is to use test layers where each layer
ensures that on "setUp" the global registries get the necessary
registrations and on "tearDown" the old state is restored
or the test continued in a new process (with new empty registry objects).


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
khink khink
Reply | Threaded
Open this post in threaded view
|

Re: testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

In reply to this post by khink
I added these methods:

class FreitagArticleLayer(PloneSandboxLayer):

     def setUp(self):
         super(FreitagArticleLayer, self).setUp()
         with ploneSite() as portal:
             pushGlobalRegistry(portal)

     def tearDown(self):
         super(FreitagArticleLayer, self).tearDown()
         with ploneSite() as portal:
             popGlobalRegistry(portal)

Without the call to super(), the test broke: the tested product didn't
seem to be installed at all. Is this normal?

With the setUp/tearDown methods above, i still get the original error,
sadly. What else could i check?

Kees

On 11/12/2012 05:26 PM, Kees Hink wrote:

> I just looked at
> http://pypi.python.org/pypi/plone.app.testing/4.2#component-architecture-sandboxing,
> and added setUp and tearDown methods, where i call
> pop/pushGlobalRegistry(), to the first package.
>
> At the moment it makes the tests for that package fail (url
> ++add++content.type.defined.in.that.package) but i've a feeling the clue
> is here somehere, so that's why i wrote this quick follow-up.
>
> On 11/12/2012 03:51 PM, Kees Hink wrote:
>> When i run tests for individual packages, all pass. When i run multiple
>> tests (./bin/test), i get an error for a utility lookup
>> (plone.app.async.interfaces.IAsyncDatabase).
>>
>> To pin down the problem more, i went into ./bin/test and commented out
>> all tests but two, f.article and f.discussion. f.article passes without
>> issue, and then f.discussion fails. (When also uncommenting f.article,
>> tests pass.)
>>
>> It seems like in this case, the un-registration for the async mailer in
>> the second packages isn't picked up at all. The test tries to send mail
>> and it goes for the async version. I'm guessing i should be able to use
>> tearDown/tearDownPloneSite (or setUp-) to prevent this, but how?
>>
>> Some background info: Neither test should use IAsyncDatabase. We use
>> plone.app.async to send mail asynchronously, which we do (and test) in
>> another package (f.util.mailer). In all other packages, we use a
>> different ZCML reistration which tells the test to unregister the async
>> mailer and use the non-async one, because otherwise writing tests would
>> be unnecessarily complicated. A typical registration for this
>> unregistration of async in F.XXX/testing.py:
>>
>> class FreitagXXXLayer(PloneSandboxLayer):
>>
>>        def setUpZope(self, app, configurationContext):
>> ...
>>            # in test, use synchronous mailer
>>            import freitag.util.mailer.tests
>>            xmlconfig.file('synchronous-mailer.zcml',
>> freitag.util.mailer.tests,
>>                           context=configurationContext)
>>
>> This unregistration of async is done in testing.py of both packages
>> under scrutiny here (because both send emails).
>>
>> I've added tearDownPloneSite and tearDown methods to the layer class in
>> the first package that gets tested (f.article), and see they are being
>> executed. When i put a pdb in tearDownPloneSite and type
>> getUtility(IAsyncDatabase)
>> i get
>> *** ComponentLookupError: (<InterfaceClass
>> plone.app.async.interfaces.IAsyncDatabase>, '')
>> which is okay because we un-registered it.
>>
>> Question is why doesn't the second package's test not unregister the
>> async mail-utility, as it does when the test is called with -m "package"?
>>
>> Kees
>>
>> [1] Stacktrace for ./bin/test
>>
>> kees@francis:~/development/zope$ ./bin/test
>> Running freitag.article.testing.FreitagArticleLayer:Functional tests:
>>      Set up plone.testing.zca.LayerCleanup in 0.000 seconds.
>>      Set up plone.testing.z2.Startup in 0.132 seconds.
>>      Set up plone.app.testing.layers.PloneFixtureCould not install product
>> plone.app.collection
>>     Enabling ++resource++plone.app.jquerytools.dateinput.js
>> Enabling ++resource++plone.app.jquerytools.dateinput.css
>> Enabling ++resource++plone.app.jquerytools.dateinput.js
>> Enabling ++resource++plone.app.jquerytools.dateinput.css
>> in 6.864 seconds.
>>      Set up freitag.article.testing.FreitagArticleLayer Enabling
>> ++resource++plone.app.jquerytools.dateinput.js
>> Enabling ++resource++plone.app.jquerytools.dateinput.css
>> Enabling ++resource++plone.app.jquerytools.dateinput.js
>> Enabling ++resource++plone.app.jquerytools.dateinput.css
>> in 8.303 seconds.
>>      Set up freitag.article.testing.FreitagArticleLayer:Functional in
>> 0.000 seconds.
>>      Running:
>>        10/12
>> (83.3%)/home/kees/.buildout/eggs/Products.PluggableAuthService-1.9.0-py2.7.egg/Products/PluggableAuthService/plugins/ZODBUserManager.py:109:
>> UnicodeWarning: Unicode equal comparison failed to convert both
>> arguments to Unicode - interpreting them as being unequal
>>      userid = self._login_to_userid.get(login)
>>
>>      Ran 12 tests with 0 failures and 0 errors in 11.998 seconds.
>> Running freitag.article.testing.FreitagArticleLayer:Integration tests:
>>      Tear down freitag.article.testing.FreitagArticleLayer:Functional in
>> 0.000 seconds.
>>      Set up freitag.article.testing.FreitagArticleLayer:Integration in
>> 0.000 seconds.
>>      Running:
>>
>>      Ran 21 tests with 0 failures and 0 errors in 1.699 seconds.
>> Running freitag.discussion.testing.FreitagDiscussionLayer:Integration tests:
>>      Tear down freitag.article.testing.FreitagArticleLayer:Integration in
>> 0.000 seconds.
>>      Tear down freitag.article.testing.FreitagArticleLayer in 0.003 seconds.
>>      Set up freitag.discussion.testing.FreitagDiscussionLayer Enabling
>> ++resource++plone.app.jquerytools.dateinput.js
>> Enabling ++resource++plone.app.jquerytools.dateinput.css
>> Enabling ++resource++plone.app.jquerytools.dateinput.js
>> Enabling ++resource++plone.app.jquerytools.dateinput.css
>> in 4.092 seconds.
>>      Set up freitag.discussion.testing.FreitagDiscussionLayer:Integration
>> in 0.000 seconds.
>>      Running:
>>        2/12 (16.7%)
>>
>> Error in test test_flag_transition
>> (freitag.discussion.tests.test_freitag_comment_workflow.FreitagCommentWorkflowTest)
>> Traceback (most recent call last):
>>      File
>> "/home/kees/.buildout/eggs/unittest2-0.5.1-py2.7.egg/unittest2/case.py",
>> line 340, in run
>>        testMethod()
>>      File
>> "/home/kees/development/zope/src/freitag.discussion/freitag/discussion/tests/test_freitag_comment_workflow.py",
>> line 67, in test_flag_transition
>>        self.wftool.doActionFor(self.comment, action='flag')
>>      File
>> "/home/kees/.buildout/eggs/Products.CMFCore-2.2.7-py2.7.egg/Products/CMFCore/WorkflowTool.py",
>> line 241, in doActionFor
>>        wfs, ob, action, wf.doActionFor, (ob, action) + args, kw)
>>      File
>> "/home/kees/.buildout/eggs/Products.CMFCore-2.2.7-py2.7.egg/Products/CMFCore/WorkflowTool.py",
>> line 552, in _invokeWithNotification
>>        res = func(*args, **kw)
>>      File
>> "/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
>> line 282, in doActionFor
>>        self._changeStateOf(ob, tdef, kw)
>>      File
>> "/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
>> line 421, in _changeStateOf
>>        sdef = self._executeTransition(ob, tdef, kwargs)
>>      File
>> "/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
>> line 531, in _executeTransition
>>        notify(AfterTransitionEvent(ob, self, old_sdef, new_sdef, tdef,
>> status, kwargs))
>>      File
>> "/home/kees/.buildout/eggs/zope.event-3.5.2-py2.7.egg/zope/event/__init__.py",
>> line 31, in notify
>>        subscriber(event)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
>> line 24, in dispatch
>>        zope.component.subscribers(event, None)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
>> line 136, in subscribers
>>        return sitemanager.subscribers(objects, interface)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
>> line 321, in subscribers
>>        return self.adapters.subscribers(objects, provided)
>>      File
>> "/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
>> line 585, in subscribers
>>        subscription(*objects)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
>> line 32, in objectEventNotify
>>        zope.component.subscribers((event.object, event), None)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
>> line 136, in subscribers
>>        return sitemanager.subscribers(objects, interface)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
>> line 321, in subscribers
>>        return self.adapters.subscribers(objects, provided)
>>      File
>> "/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
>> line 585, in subscribers
>>        subscription(*objects)
>>      File
>> "/home/kees/development/zope/src/freitag.discussion/freitag/discussion/handlers.py",
>> line 59, in notify_comment_reviewer
>>        notify(MailEvent(mail_message, mail_to, subject=mail_subject))
>>      File
>> "/home/kees/.buildout/eggs/zope.event-3.5.2-py2.7.egg/zope/event/__init__.py",
>> line 31, in notify
>>        subscriber(event)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
>> line 24, in dispatch
>>        zope.component.subscribers(event, None)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
>> line 136, in subscribers
>>        return sitemanager.subscribers(objects, interface)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
>> line 321, in subscribers
>>        return self.adapters.subscribers(objects, provided)
>>      File
>> "/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
>> line 585, in subscribers
>>        subscription(*objects)
>>      File
>> "/home/kees/development/zope/src/freitag.util.mailer/freitag/util/mailer/handlers.py",
>> line 183, in handler_asynchronous_send_mail
>>        queue(job)
>>      File
>> "/home/kees/.buildout/eggs/plone.app.async-1.6-py2.7.egg/plone/app/async/utils.py",
>> line 22, in queue
>>        queue = service.getQueues()['']
>>      File
>> "/home/kees/.buildout/eggs/plone.app.async-1.6-py2.7.egg/plone/app/async/service.py",
>> line 100, in getQueues
>>        db = getUtility(IAsyncDatabase)
>>      File
>> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
>> line 169, in getUtility
>>        raise ComponentLookupError(interface, name)
>> ComponentLookupError: (<InterfaceClass
>> plone.app.async.interfaces.IAsyncDatabase>, '')
>>
>>
>>      Ran 12 tests with 0 failures and 1 errors in 0.637 seconds.
>> Tearing down left over layers:
>>      Tear down
>> freitag.discussion.testing.FreitagDiscussionLayer:Integration in 0.000
>> seconds.
>>      Tear down freitag.discussion.testing.FreitagDiscussionLayer in 0.005
>> seconds.
>>      Tear down plone.app.testing.layers.PloneFixture in 0.045 seconds.
>>      Tear down plone.testing.z2.Startup in 0.004 seconds.
>>      Tear down plone.testing.zca.LayerCleanup in 0.001 seconds.
>> Total: 45 tests, 0 failures, 1 errors in 34.619 seconds.
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_nov
>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
>


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
Dieter Maurer Dieter Maurer
Reply | Threaded
Open this post in threaded view
|

Re: testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

Kees Hink <[hidden email]> writes:

> I added these methods:
>
> class FreitagArticleLayer(PloneSandboxLayer):
>
>      def setUp(self):
>          super(FreitagArticleLayer, self).setUp()
>          with ploneSite() as portal:
>              pushGlobalRegistry(portal)
>
>      def tearDown(self):
>          super(FreitagArticleLayer, self).tearDown()
>          with ploneSite() as portal:
>              popGlobalRegistry(portal)
>
> Without the call to super(), the test broke: the tested product didn't
> seem to be installed at all. Is this normal?

The "super" calls should not be necessary. It is the task of the
test runner framework to set up once a layer is entered and
tear down once the layer is left. There is not additional set up/tead down
related to the layer for tests or sublayers in this layer.

The layer implementation slightly abuses inheritance to declare
an inheriting layer to be a sublayer of the base.


As your place, I would investigate why your test breaks without
the "super" calls.


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
khink khink
Reply | Threaded
Open this post in threaded view
|

Re: testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

Thanks Dieter for a useful pointer. I think i found that reason: The
methods that are supposed to install the product are setUpZope and
setUpPloneSite. These aren't executed when a setUp() method is present.

The setUp method in PloneSandboxLayer (from plone.app.testing.helpers)
gets overridden, and that did a call to setUpZope and setUpPloneSite. So
we'd have to move the relevant code out of there, and into our custom
setUp method.

While looking at that, i noticed PloneSandboxLayer.setUp also does a
call to pushGlobalRegistry(), so adding a custom setUp method to our
layer to call that method doesn't make sense anymore.

The question that remains is: Why is the default event handler
registered when we enter the f.discussion tests?

I'm now inspecting the handlers in the global site manager
(zope.component.getGlobalSiteManager().registeredHandlers()) in various
parts of the testing code to see where it goes wrong.

On 11/14/2012 08:09 AM, Dieter Maurer wrote:

> Kees Hink <[hidden email]> writes:
>
>> I added these methods:
>>
>> class FreitagArticleLayer(PloneSandboxLayer):
>>
>>       def setUp(self):
>>           super(FreitagArticleLayer, self).setUp()
>>           with ploneSite() as portal:
>>               pushGlobalRegistry(portal)
>>
>>       def tearDown(self):
>>           super(FreitagArticleLayer, self).tearDown()
>>           with ploneSite() as portal:
>>               popGlobalRegistry(portal)
>>
>> Without the call to super(), the test broke: the tested product didn't
>> seem to be installed at all. Is this normal?
>
> The "super" calls should not be necessary. It is the task of the
> test runner framework to set up once a layer is entered and
> tear down once the layer is left. There is not additional set up/tead down
> related to the layer for tests or sublayers in this layer.
>
> The layer implementation slightly abuses inheritance to declare
> an inheriting layer to be a sublayer of the base.
>
>
> As your place, I would investigate why your test breaks without
> the "super" calls.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
>


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
Dieter Maurer Dieter Maurer
Reply | Threaded
Open this post in threaded view
|

Re: testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

Kees Hink <[hidden email]> writes:

> The setUp method in PloneSandboxLayer (from plone.app.testing.helpers)
> gets overridden

That sounds strange.

Let me explain again:

If you have:

   class BaseLayer:
     def setUp(self): ...

   class SubLayer(BaseLayer):
     def setUp(self): ...

Then "SubLayer.setUp" does not override "BaseLayer.setUp".

Instead "BaseLayer.setUp()" is called when tests in
the "BaseLayer" begin and "SubLayer.setUp()" is called when
the tests subset corresponding to "SubLayer" starts to become
executed.


I think it was not the best idea to use class inheritance
to model layer inclusion...
An attribute "containing_layer" would probably have been better.


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
khink khink
Reply | Threaded
Open this post in threaded view
|

Re: testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

Hi Dieter, thanks for your comments again.

>> The setUp method in PloneSandboxLayer (from plone.app.testing.helpers)
>> gets overridden
>
> That sounds strange.

I've thought about that comment, and after consideration, i think the
behavior is not so strange. (We might not have been talking about the
same thing though, so let me be boringly specific :) )

According to [1], PloneSandboxLayer can be extended "To make things
easier". If i see correctly, it takes away the trouble of defining a
setUp method (which sets up the storage, registration, etc.). Simply
adding a setUp method to the extending class _will_ override
PloneSandboxLayer's setUp method. I can't find any package (in a default
Plone 4.2 install) with a test layer that both extends PloneSandboxLayer
and defines a setUp method. (It was my unfamiliarity with the purpose of
PloneSandboxLayer that caused me to try adding a setUp there, mea
culpa.) If you know of a test layer that both extends PloneSandboxLayer
as shown in [1] and adds a setUp method which doesn't override
PloneSandboxLayer's please show me.

> Let me explain again:
>
> If you have:
>
>     class BaseLayer:
>       def setUp(self): ...
>
>     class SubLayer(BaseLayer):
>       def setUp(self): ...
>
> Then "SubLayer.setUp" does not override "BaseLayer.setUp".
>
> Instead "BaseLayer.setUp()" is called when tests in
> the "BaseLayer" begin and "SubLayer.setUp()" is called when
> the tests subset corresponding to "SubLayer" starts to become
> executed.

Well, in a layer that is not defined by extending PloneSandboxLayer as
described in [1], this may well be the case, and
(setUp/tearDown)(Zope/PloneSite) methods also work like this. (This
might be where we were talking about different things.)

> I think it was not the best idea to use class inheritance
> to model layer inclusion...
> An attribute "containing_layer" would probably have been better.

If this is meant as a note on the general layers implementation in
plone(.app)/zope.testing, or do you that see an improvement for our test
setup? In the latter case, i'm grateful for the hint and curious: is
there an example of this out there?

Thanks for taking the time to share your thoughts - i hope that my reply
makes things more clear. (If not, feel free to also ping me on IRC -
nick khink - if you want.)

Kees

[1] http://pypi.python.org/pypi/plone.app.testing/4.2#layer-base-class


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
khink khink
Reply | Threaded
Open this post in threaded view
|

Re: testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

In reply to this post by khink
Solved.

The synchronous-mailer.zcml (in our low-level mailer package) did

   <!-- unset existing handler -->
   <include package=".unsetHandler" />

   <!-- Use synchronous mail sending in our tests -->
   <subscriber
     for="freitag.util.mailer.interfaces.IMailEvent"
     handler="freitag.util.mailer.handlers.handler_synchronous_send_mail"
     />

unsetHandler.py:

from zope.component import getGlobalSiteManager

from freitag.util.mailer.handlers import handler_asynchronous_send_mail
from freitag.util.mailer.interfaces import IMailEvent

gsm = getGlobalSiteManager()
_ = gsm.unregisterHandler(handler_asynchronous_send_mail, [IMailEvent])

Calling the python code in this manner apparently works when testing
individual packages, but not when running all tests (and there is more
than one package being tested which calls the zcml).

We now moved the python code into the setUpZope methods of the test
layers of the packages that use the mailer, that fixes it.

Kees

On 11/12/2012 03:51 PM, Kees Hink wrote:

> When i run tests for individual packages, all pass. When i run multiple
> tests (./bin/test), i get an error for a utility lookup
> (plone.app.async.interfaces.IAsyncDatabase).
>
> To pin down the problem more, i went into ./bin/test and commented out
> all tests but two, f.article and f.discussion. f.article passes without
> issue, and then f.discussion fails. (When also uncommenting f.article,
> tests pass.)
>
> It seems like in this case, the un-registration for the async mailer in
> the second packages isn't picked up at all. The test tries to send mail
> and it goes for the async version. I'm guessing i should be able to use
> tearDown/tearDownPloneSite (or setUp-) to prevent this, but how?
>
> Some background info: Neither test should use IAsyncDatabase. We use
> plone.app.async to send mail asynchronously, which we do (and test) in
> another package (f.util.mailer). In all other packages, we use a
> different ZCML reistration which tells the test to unregister the async
> mailer and use the non-async one, because otherwise writing tests would
> be unnecessarily complicated. A typical registration for this
> unregistration of async in F.XXX/testing.py:
>
> class FreitagXXXLayer(PloneSandboxLayer):
>
>       def setUpZope(self, app, configurationContext):
> ...
>           # in test, use synchronous mailer
>           import freitag.util.mailer.tests
>           xmlconfig.file('synchronous-mailer.zcml',
> freitag.util.mailer.tests,
>                          context=configurationContext)
>
> This unregistration of async is done in testing.py of both packages
> under scrutiny here (because both send emails).
>
> I've added tearDownPloneSite and tearDown methods to the layer class in
> the first package that gets tested (f.article), and see they are being
> executed. When i put a pdb in tearDownPloneSite and type
> getUtility(IAsyncDatabase)
> i get
> *** ComponentLookupError: (<InterfaceClass
> plone.app.async.interfaces.IAsyncDatabase>, '')
> which is okay because we un-registered it.
>
> Question is why doesn't the second package's test not unregister the
> async mail-utility, as it does when the test is called with -m "package"?
>
> Kees
>
> [1] Stacktrace for ./bin/test
>
> kees@francis:~/development/zope$ ./bin/test
> Running freitag.article.testing.FreitagArticleLayer:Functional tests:
>     Set up plone.testing.zca.LayerCleanup in 0.000 seconds.
>     Set up plone.testing.z2.Startup in 0.132 seconds.
>     Set up plone.app.testing.layers.PloneFixtureCould not install product
> plone.app.collection
>    Enabling ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> Enabling ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> in 6.864 seconds.
>     Set up freitag.article.testing.FreitagArticleLayer Enabling
> ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> Enabling ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> in 8.303 seconds.
>     Set up freitag.article.testing.FreitagArticleLayer:Functional in
> 0.000 seconds.
>     Running:
>       10/12
> (83.3%)/home/kees/.buildout/eggs/Products.PluggableAuthService-1.9.0-py2.7.egg/Products/PluggableAuthService/plugins/ZODBUserManager.py:109:
> UnicodeWarning: Unicode equal comparison failed to convert both
> arguments to Unicode - interpreting them as being unequal
>     userid = self._login_to_userid.get(login)
>
>     Ran 12 tests with 0 failures and 0 errors in 11.998 seconds.
> Running freitag.article.testing.FreitagArticleLayer:Integration tests:
>     Tear down freitag.article.testing.FreitagArticleLayer:Functional in
> 0.000 seconds.
>     Set up freitag.article.testing.FreitagArticleLayer:Integration in
> 0.000 seconds.
>     Running:
>
>     Ran 21 tests with 0 failures and 0 errors in 1.699 seconds.
> Running freitag.discussion.testing.FreitagDiscussionLayer:Integration tests:
>     Tear down freitag.article.testing.FreitagArticleLayer:Integration in
> 0.000 seconds.
>     Tear down freitag.article.testing.FreitagArticleLayer in 0.003 seconds.
>     Set up freitag.discussion.testing.FreitagDiscussionLayer Enabling
> ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> Enabling ++resource++plone.app.jquerytools.dateinput.js
> Enabling ++resource++plone.app.jquerytools.dateinput.css
> in 4.092 seconds.
>     Set up freitag.discussion.testing.FreitagDiscussionLayer:Integration
> in 0.000 seconds.
>     Running:
>       2/12 (16.7%)
>
> Error in test test_flag_transition
> (freitag.discussion.tests.test_freitag_comment_workflow.FreitagCommentWorkflowTest)
> Traceback (most recent call last):
>     File
> "/home/kees/.buildout/eggs/unittest2-0.5.1-py2.7.egg/unittest2/case.py",
> line 340, in run
>       testMethod()
>     File
> "/home/kees/development/zope/src/freitag.discussion/freitag/discussion/tests/test_freitag_comment_workflow.py",
> line 67, in test_flag_transition
>       self.wftool.doActionFor(self.comment, action='flag')
>     File
> "/home/kees/.buildout/eggs/Products.CMFCore-2.2.7-py2.7.egg/Products/CMFCore/WorkflowTool.py",
> line 241, in doActionFor
>       wfs, ob, action, wf.doActionFor, (ob, action) + args, kw)
>     File
> "/home/kees/.buildout/eggs/Products.CMFCore-2.2.7-py2.7.egg/Products/CMFCore/WorkflowTool.py",
> line 552, in _invokeWithNotification
>       res = func(*args, **kw)
>     File
> "/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
> line 282, in doActionFor
>       self._changeStateOf(ob, tdef, kw)
>     File
> "/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
> line 421, in _changeStateOf
>       sdef = self._executeTransition(ob, tdef, kwargs)
>     File
> "/home/kees/.buildout/eggs/Products.DCWorkflow-2.2.4-py2.7.egg/Products/DCWorkflow/DCWorkflow.py",
> line 531, in _executeTransition
>       notify(AfterTransitionEvent(ob, self, old_sdef, new_sdef, tdef,
> status, kwargs))
>     File
> "/home/kees/.buildout/eggs/zope.event-3.5.2-py2.7.egg/zope/event/__init__.py",
> line 31, in notify
>       subscriber(event)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
> line 24, in dispatch
>       zope.component.subscribers(event, None)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
> line 136, in subscribers
>       return sitemanager.subscribers(objects, interface)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
> line 321, in subscribers
>       return self.adapters.subscribers(objects, provided)
>     File
> "/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
> line 585, in subscribers
>       subscription(*objects)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
> line 32, in objectEventNotify
>       zope.component.subscribers((event.object, event), None)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
> line 136, in subscribers
>       return sitemanager.subscribers(objects, interface)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
> line 321, in subscribers
>       return self.adapters.subscribers(objects, provided)
>     File
> "/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
> line 585, in subscribers
>       subscription(*objects)
>     File
> "/home/kees/development/zope/src/freitag.discussion/freitag/discussion/handlers.py",
> line 59, in notify_comment_reviewer
>       notify(MailEvent(mail_message, mail_to, subject=mail_subject))
>     File
> "/home/kees/.buildout/eggs/zope.event-3.5.2-py2.7.egg/zope/event/__init__.py",
> line 31, in notify
>       subscriber(event)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/event.py",
> line 24, in dispatch
>       zope.component.subscribers(event, None)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
> line 136, in subscribers
>       return sitemanager.subscribers(objects, interface)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/registry.py",
> line 321, in subscribers
>       return self.adapters.subscribers(objects, provided)
>     File
> "/home/kees/.buildout/eggs/zope.interface-3.6.7-py2.7-linux-x86_64.egg/zope/interface/adapter.py",
> line 585, in subscribers
>       subscription(*objects)
>     File
> "/home/kees/development/zope/src/freitag.util.mailer/freitag/util/mailer/handlers.py",
> line 183, in handler_asynchronous_send_mail
>       queue(job)
>     File
> "/home/kees/.buildout/eggs/plone.app.async-1.6-py2.7.egg/plone/app/async/utils.py",
> line 22, in queue
>       queue = service.getQueues()['']
>     File
> "/home/kees/.buildout/eggs/plone.app.async-1.6-py2.7.egg/plone/app/async/service.py",
> line 100, in getQueues
>       db = getUtility(IAsyncDatabase)
>     File
> "/home/kees/.buildout/eggs/zope.component-3.9.5-py2.7.egg/zope/component/_api.py",
> line 169, in getUtility
>       raise ComponentLookupError(interface, name)
> ComponentLookupError: (<InterfaceClass
> plone.app.async.interfaces.IAsyncDatabase>, '')
>
>
>     Ran 12 tests with 0 failures and 1 errors in 0.637 seconds.
> Tearing down left over layers:
>     Tear down
> freitag.discussion.testing.FreitagDiscussionLayer:Integration in 0.000
> seconds.
>     Tear down freitag.discussion.testing.FreitagDiscussionLayer in 0.005
> seconds.
>     Tear down plone.app.testing.layers.PloneFixture in 0.045 seconds.
>     Tear down plone.testing.z2.Startup in 0.004 seconds.
>     Tear down plone.testing.zca.LayerCleanup in 0.001 seconds.
> Total: 45 tests, 0 failures, 1 errors in 34.619 seconds.
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
>


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users
Dieter Maurer Dieter Maurer
Reply | Threaded
Open this post in threaded view
|

Re: testing: un-registration of utility not consistent between test (improper setUp/tearDown?)

In reply to this post by khink
Kees Hink <[hidden email]> writes:

>>> The setUp method in PloneSandboxLayer (from plone.app.testing.helpers)
>>> gets overridden
>>
>> That sounds strange.
>
> I've thought about that comment, and after consideration, i think the
> behavior is not so strange. (We might not have been talking about the
> same thing though, so let me be boringly specific :) )
>
> According to [1], PloneSandboxLayer can be extended "To make things
> easier". If i see correctly, it takes away the trouble of defining a
> setUp method (which sets up the storage, registration, etc.). Simply
> adding a setUp method to the extending class _will_ override
> PloneSandboxLayer's setUp method.

I have carefully read [1] but I could not see any hint that the
last sentence was true. And it would really surprise me.

Look at the standard layer use case:
 
   test base layer set up
   ... perform some tests, all using the common test base layer set up
   ... start tests in sublayer
       sublayer test setup: base layer setup should not be repeated, as it is already there
       ... perform tests in sublayer
       sublayer test teardown: base layer teardown must not be performed, at the base layer infrastructure is still needed for following tests.
   ... perform some tests (in base layer again)

> ...
> If you know of a test layer that both extends PloneSandboxLayer
> as shown in [1] and adds a setUp method which doesn't override
> PloneSandboxLayer's please show me.

I don't.

But I know the "layer" specification. You can find it in
"zope.testing.testrunner:testrunner-layers-api.txt".
And it says:

> Layers can extend other layers. Note that they do not explicitly
> invoke the setup and teardown methods of other layers - the test runner
> does this for us in order to minimize the number of invocations.

Thus, a sublayer's "setUp" method does not override the "setUp"
method of a base layer. Instead, the base layer "setUp" (if any)
is called when the base layer is set up and the sublayer "setUp" (if
any is explicitely defined, not inherited) is called when
the sublayer is set up. Similar things apply to the other
layer methods ("tearDown", "testSetUp", "testTearDown").

Of course, this has importance only, if we speak about the same
"layer" concept, i.e. if you are using "zope.testing" as the (ultimate)
test runner.


> ...
> Well, in a layer that is not defined by extending PloneSandboxLayer as
> described in [1], this may well be the case, and
> (setUp/tearDown)(Zope/PloneSite) methods also work like this. (This
> might be where we were talking about different things.)

Maybe.

I will not exclude that "PloneSandboxLayer" might contain
magic that works against the "zope.testing" "layer" concept.
It would surprise me -- but it might well be possible.


>> I think it was not the best idea to use class inheritance
>> to model layer inclusion...
>> An attribute "containing_layer" would probably have been better.
>
> If this is meant as a note on the general layers implementation in
> plone(.app)/zope.testing, or do you that see an improvement for our test
> setup?

This is a general remark about the "layer" concept of "zope.testing".


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Plone-Users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-users