Florent Guillaume wrote:
Geoff Davis wrote:

I'm sure I won't do Stefan's work full justice (feel free to chime in,
Stefan!).  The most important thing in my mind that ZopeTestCase does is
to make it simpler to set up your test fixture.  ZopeTestCase creates a
new folder to work in, adds a user folder, and creates a user.  It
provides methods to log in and out, to set permissions assigned to a role,
and to set roles assigned to users.

We ship a subclass of ZopeTestCase with Plone called PloneTestCase.  An
instance of PloneTestCase creates a Plone site for you, installs a base
set of associated products, creates two members of the site, one with
Manager role and one with Member role, and creates folders owned by each. It provides convenience methods for importing and installing additional products, for logging in as given member, and so on.

However this kind of default fixture actually is quite heavy, and makes you write tests that are hardly "unit" anymore. They are still good integration tests, but I've found that using PortalTestCase or something like that is often extremely costly in terms of time spent running the tests.

Agreed. Nevertheless we should focus on lowering the barrier of entry for new CMF contributors. People used to write tests for Zope or Plone will have less trouble if they can use ZopeTestCase. And ZopeTestCase tests are definitely better than no tests at all.

On the other hand I'm not sure if it is a good idea to use PortalTestCase (shipped with ZopeTestCase):

PortalTestCase is in the wrong layer. It makes assumptions about the way CMF works. Changes to the CMF might break PortalTestCase and create a dependency on a new Zope release. (We saw that problem already with the _refreshSkinData changes in CMF 1.5)

Cheers, Yuppie

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

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

Reply via email to