[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn

yuppie y.2005- at wcm-solutions.de
Thu Sep 8 13:24:51 EDT 2005

Hi Geoff!

Geoff Davis wrote:
> On Thu, 08 Sep 2005 12:08:23 +0200, yuppie wrote:
>>- Tests are easier to find and maintain if they are located in 
>>test_<module_name>.py. Most CMF tests follow that pattern.
> Yes, I put the tests relating to new CachingPolicyManager functionality
> into test_CachingPolicyManager.py.  The other tests I added were
> integration tests that check how CachingPolicyManager interacts with
> FSPageTemplate.py.  I didn't really think those tests were appropriate for
> either test_CachingPolicyManager.py or test_FSPageTemplate.py.  Instead I
> put them in test_Template304Handling.py, and I tried to convey the
> functionality being tested in the file name.  I'm open to other naming
> suggestions, though.

Ok. I see your point.

In the first place those tests seem to test CachingPolicyManager 
features, so I would have added them to test_CachingPolicyManager.py. 
But maybe that's just me.

>>>PS  Those of you who raised concerns about ZopeTestCase causing test
>>>problems in Zope 2.7 might want to take a look at why test_z3interfaces is
>>>broken when you run the tests with zopectl test.
>>2.) Please note that I raised concerns about using PortalTestCase.

Knock! Knock! Anybody there?

I told you twice that I'm concerned about using PortalTestCase:

Would be nice to get some feedback. Obviously you don't share those 
concerns. What do you propose to do if changes in CMF make a new version 
of PortalTestCase necessary?

Florent also raised (different) concerns about using PortalTestCase:

>>3.) Please be more specific. I can't reproduce any problems with 
> Yeah, sorry to sound cranky here -- I'm in the middle of a nasty
> deployment.


> I put in some effort getting my tests to degrade quietly for
> Zope 2.7 only to find some other Zope 2.7 problems with the tests.  It
> could be it's my setup, though -- I'm not sure.  When running the tests
> with a fresh checkout of the 1.5 branch on Zope 2.7.7 using
> bin/zopectl test --dir Products/CMFCore/tests
> I get a bunch of errors like the following:
> ======================================================================
> ERROR: test_z3interfaces (CMFCore.tests.test_ActionInformation.ActionInfoTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/home/zope/plonedev/Products/CMFCore/tests/test_ActionInformation.py", line 60, in test_z3interfaces
>     from Products.CMFCore.interfaces import IActionInfo
> ImportError: cannot import name IActionInfo
> I don't see IActionInfo defined anywhere in interfaces, so I don't think
> it's just me.

The z3interfaces tests are based on the assumption that Five is 
available if zope.interface is available. Five creates IActionInfo 
dynamically on startup.

That's obviously not true in your setup. Looking again at these tests it 
would be more robust to include the interface imports in the try/except 
ImportError statement.

> One other frustration: I was able to run my new tests in isolation, but
> when I ran the whole test suite, they failed.  The problem appears to be
> that somehow some things that happen in test_ActionProviderBase.py are not
> being cleaned up before test_Template304Handling.py.  Some items placed in
> the CMFSetup profile registry in test_ActionProviderBase.py are still
> present when test_Template304Handling.py runs.  I added a workaround that
> clears out profile_registry, but that shouldn't be necessary.  I don't
> know if the problem is with the test runner or with
> test_ActionProviderBase.py, but it's definitely bad that state from one
> test is affecting another.  This problem appeared in both Zope 2.7.7 and
> Zope 2.8.1.

I guess ZopeTestCase installs again products that are already installed. 
The registry raises errors if the same product is registered twice.

Not sure how to resolve this.



More information about the Zope-CMF mailing list