[Zope3-Users] Re: Moving from z3 tarball to z3 buildout/eggs

[Philipp von Weitershausen]

Derek Richardson wrote:
> The problem is that I don't know how much of zope.app these tests depend 
> on. Very few eggs are actually required by imports in Vice. But the 
> library is not much use (and there's not much to test) without a pretty 
> thorough install, I suspect. Should I be attempting to grab all the zope 
> eggs and making a replica of the full install?

No.

> Or should I be trying to judiciously minimize the eggs that I use for testing?

Yes.

> And what is the best way to go about whichever of these paths I should follow?

I suppose you can do this inductively (start ftesting.zcml from scratch) 
or deductively (start out with a full-fledged ftesting.zcml and remove 
things).

If you want to do things inductively, there are a few hints I can give you:

* If vice depends on the configuration of another package, but always 
assumed that this package's configuration was being loaded by Zope 3.3's 
site.zcml, make this dependency *explicit* now in vice's configure.zcml. 
For example, let's say that vice needs the intid utility and event 
subscriber registrations to be active, then it should do:

   <include package="zope.app.intid" />

at the top of vice/configure.zcml. This will probably add more explicit 
depenencies to vice than you currently have (they should also go into 
setup.py). Note that you won't have to worry about ZCML being loaded 
several times. It won't be, zope.configuration makes sure of that.

* ftesting.zcml should <include package="vice" /> somewhere, therefore 
load all of its direct dependencies anyway. Then you should check which 
dependencies your tests have. You mention folders and other things. So 
you probably want to include zope.app.zcmlfiles/configure.zcml (which is 
the old 'zope.app/configure.zcml') because that pretty much loads the 
basic Zope 3 stuff.

* Don't forget to load the meta stuff first. This usually boils down to:

     <include package="zope.security" file="meta.zcml" />
     <include package="zope.i18n" file="meta.zcml" />
     <include package="zope.app.zcmlfiles" file="meta.zcml" />

   and the security policy's meta.zcml if you want to define roles:

     <include package="zope.app.securitypolicy" file="meta.zcml" />

* You'll need to define a security policy. Usually we take 
zope.app.securitypolicy for that:

   <include package="zope.app.securitypolicy" />
   <securityPolicy
       component="zope.app.securitypolicy.zopepolicy.ZopeSecurityPolicy" />

Then you want to define the standard principals that are needed in 
ftests (anonmyous, the manager, etc.). Look at Zope 3.3's ftesting.zcml 
for those (incl. the grants).

> I *really* like the buildout approach. It would just be even nicer if I 
> knew of some way to have buildout replicate the entire Zope app server 
> ecosystem for testing without having to specify the eggs one ... by ... 
> one.

I think it's much better to sit down for a moment and *just* load the 
things you really need in tests. Usually this leads to much better 
tests. May I just remind of the horrid PloneTestCase which people have 
simply started using for every tests, which has cause Plone tests to be 
poorly isolated, quite slow and depend on much too many things at once.

The path to a truly eggified system is to think about dependencies and 
write good tests that only load a minimum load of dependencies. This is 
not a trivial task. Testing never is. And I don't think there's a silver 
bullet, either.


-- 
http://worldcookery.com -- Professional Zope documentation and training