[Zope-ZEO] Advice

[Jim Fulton]

Toby Dickenson wrote:
> 
> On Fri, 22 Sep 2000 19:54:11 -0400, Andrew Kuchling
> <akuchlin@cnri.reston.va.us> wrote:
> 
> >  You could write a Python object, test it from the Python
> >command-line, and then write a layer of glue on top of it to turn it into a
> >Product,
> 
> Thats a good strategy - I assume you do (or could) use a similar one
> for Quixote applications.
> 
> >  but how do you test the glue?
> 
> I assume the strategy for testing Zope-glue is similar to
> Quixote-glue.
> 
> After perfoming units tests on individual python modules, my test
> harness includes a script which does the following:
> 
> 1. Copy an initial data.fs file from cvs. This file contains a
>    starting data set, including old formats of any objects that
>    use __setstate__

This raises an interesting point. The fact that the database
can capture complex state to provide context for a test is
a big win.

> 2. Start Zope on a different port, using DemoStorage;
>    http://www.zope.org/Members/jens/docs/zope_on_cdrom
>    this stores ZODB writes in memory.
> 3. Excercise the glue using a mix of xmlrpc (mostly),
>    httplib (a little), and sockets (rarely)
> 4. Stop Zope.

I think it is really much easier to use ZPublisher/Test
(which is also available as Zope.debug:
 
   import Zope
   Zope.debug(url)

This provides a much thinner and more easily 
controlled environment.

I like your ideas of using DemoStorage.  This
allows you to really test interactions with the
persistence system without making persistent changes.
The alternative would be to install a null transaction
manager, but this wouldn't provide a faithful 
simulation of persistence behavior as use of 
DemoStorage does.
 
> The key to this is (as always) ensuring that your design process
> considers the testability of the glue.

What do you mean by glue?

> Several key technologies can very quickly make this glue untestable if
> used unwisely. For example, the DTML namespace - theres so much mixed
> up into one mapping object that it can be hard to prove that it always
> finds the object. (The other sticky point is Acquisition, combined
> with ObjectManager/PropertyManager implementations that modify the
> namespace searched by Acquisition)

How does this make anything untestable?  You certainly can decide
correct and incorrect behavior.  I think there is much more possibility
of problems due to UI changes or dynamism that make analysis of
test results difficult.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.