On 5/10/12 9:24 AM, Sean Upton wrote:
I'm using a homegrown CMF site fixture/layer with plone.testing for
testing add-ons that require CMF but not Plone (and possibly also are
non-GPL e.g. MIT/BSD/ZPL type licenses). What I have done thus far is
minimal -- just the tiny bits I need to test: create a site class
subclassing Products.CMFCore.PortalObject.PoralObjectBase, and add a
portal_catalog to that site, and this runs inside a layer based on
plone.testing.z2.STARTUP.
This seems useful to me because it gives me a way of resolving items
in a site via a catalog, and it gives me a persistent component
registry to test against. It also is much faster to set up and tear
down than a fully-blown Plone site, which is advantageous for packages
that have minimal coupling with Plone.
Is this something that might (eventually) be useful to others as an
added layer in plone.testing itself (assuming another optional extra
called 'cmf', and a layer resource called 'site')?
Why not 'portal', since that's what's used in the Plone fixture,
CMFTestCase, and PortalTestCase in Zope2's Testing package?
If so, what OOTB CMF tools and fixtures would you want in a CMF site
fixture for testing?
Also, is there any point in using / requiring CMFDefault if a fixture
based on CMFCore will suffice? My goal would be only adding extra
dependency on CMFCore only.
+1 for not requiring CMFDefault, and for the proposal in general.
David
----------
David Glick
Web Developer
[email protected]
206.286.1235x32
Are you engaging? Find out! Use our free engagement benchmarking tool.
http://groundwire.org/labs/engagement-strategy/diy-benchmarking-survey
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
