> 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. -PW _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests