[Zope-ZEO] Advice

[Toby Dickenson]

On Mon, 25 Sep 2000 09:03:32 -0400, Jim Fulton <jim@digicool.com>
wrote:

>> 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.

I wouldnt go that far... any application-level persistence scheme can
be abused for holfing test state; ZODB is nothing special in that
respect.

>> 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.

... but not a complete replication of the deployed environment. For
example, you cant test RESPONSE.write.

From a philosophical point of view, using Zope.debug is wrong because
the whole purpose is an integration test of the interactions of your
pre-tested components with the Zope environment (depending on the
complexity of your glue, you may also think of it as a unit test of
that glue).

>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?

The layer which allows Zope-ignorant code to be used as a Zope
product. ZCatalog.py is an example of glue for Catalog.py.

Im not particularly happy with the name "glue" - my glue is often
thicker than that name implies.

>> 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.

I suspect our difference in opinion is the scope of what we are
testing. Is it a bug if a product can be broken by a Manager using the
management interface of an instance of a different product?

Should this 'bug' be tested for?

If so, then a test plan must verify that every dtml-namespace and
every acquisition name lookup can never be subverted by an
ObjectManager or PropertyManager instance, no matter how the instances
are arranged in containers.

The alternative is that the Manager take responsibility for not
creating any objects with a conflicting name - but who decides which
names are disallowed. How do you test that this list is complete?

I dont see a way to test this constraint, and it has proven impossible
to avoid the problems using design rules. I recently checked some of
our recent products using strategically placed debugging __getattr__
hooks - with initially horrifying results.



Toby Dickenson
tdickenson@geminidataloggers.com