> 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 "
.... 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:
# see PortalTestCase. This must be defined to create the portal.
name = ZopeTestCase.portal_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