> Hi Stefan!
> Stefan H. Holek wrote:
>> Well, you are supposed to use a subclass anyway, and in that subclass
>>  you can fix everything, even _refreshSkinData.
> Sure there are ways to work around the problems. But nevertheless Zope
> should not contain code that requires knowledge about the CMF.

Yes! Maybe PortalTestCase.py should be moved into CMFTestCase?
Certainly by zope 2.9 I think we should not ship PortalTestCase with
Zope.  Maybe in the next 2.8 release, ZopeTestCase/PortalTestCase.py
could give a deprecation warning at import time, like:

warnings.warn("ZopeTestCase will no longer include PortalTestCase as of "
              "Zope 2.9.  Tests should be migrated to use CMFTestCase "
              "instead.", DeprecationWarning)

.... or whatever the policy will be.

>> Maybe I should make
>> PortalTestCase truly abstract to emphasize the point.
>> NotImplementedError anyone? :-)
> What ever helps to convince Sidnei and Geoff not to check in tests that
> use PortalTestCase directly ;)

Indeed, this point is not clear in the PortalTestCase docs.
I (perhaps foolishly) wrote a bunch of tests like so:

class MyTestCase(ZopeTestCase.PortalTestCase):

    def getPortal(self):
        # see PortalTestCase. This must be defined to create the portal.
        name = ZopeTestCase.portal_name
        manage_addCMFSite(self.app, name)
        return self.app[name]

Which, perhaps by luck, worked just fine in fifty tests in two products;
but failed (BadRequest because the test fixture stuck around between tests)
in the product I'm working on this week. I never did figure out what
was significantly different about that one. I banged my head on fiddling
with transactions, sandboxes, beforeTearDown(), beforeClose(), etc.
for many hours before a suggestion led me to try CMFTestCase and only
create the portal once. Problem solved.


Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to