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