On Fri, 09 Sep 2005 08:45:05 -0500, Paul Winkler wrote:
> 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.
Yes, I think you are exactly right: CMFTestCase would make a worthy
addition to the CMF, in which case PortalTestCase could be eliminated (or
moved to the CMF if it continues to serve as a useful base class)
> 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):
> 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.
Yes, I am doing the same thing in the test that has yuppie up in arms.
It's fine for an individual test, but as you say, the right approach is
moving CMFTestCase to the CMF and using that.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests