[Zope-dev] Testing Zope applications

[Toby Dickenson]

On Mon, 25 Sep 2000 12:41:21 -0400, Jim Fulton <jim@digicool.com>
wrote:

>But Zope.debug uses the Zope environment.  Unless you consider ZServer
>a critical part of the Zope environment.  It is extremely
>rare for the difference between something like ZServer and
>ZPublisher.Test to have any noticable impact on the application
>behavior.

This skepticism has served me well; I have already submitted several
reports & patches for bugs in Zope's ZServer.HTTPResponse.write
implementation.

Having said that, I do agree that for most applications this
difference is not critical.

[much snippage; I agree with it all]

>> 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.
>
>It sounds like this is a problem that needs to be addressed.
>It's not really a testing problem, but an architecture problem

Agreed. Don't all testability problems originate with architecture
problems?

(apart from the 'I cant be bothered; testing is boring' problem ;-)

>I'm not sure exactly what problem you are refering to. It sound's
>like an issue of depending on a specific acquired name and having
>the name overridden with something bogus. Is that it?

There are two related issues that conspire to make the problem hard:

A. What you descibe above, that looks like it will be fixed in part
   by NO_SUBOBJECTS_OVERRIDE (which looks great). The outstanding
   issue is what happens when a new version of a product wants to
   add a new NO_SUBOBJECTS_OVERRIDE name (when objects of that
   name may already exist in old subobjects).

   In many cases these to-be-protected names are part of a
   product's API.
   http://dev.zope.org/Wikis/DevSite/Proposals/APINamingConvention
   suggests a naming convention for new API attributes. I suggested
   in the discussion Wiki that it should not be possible to create
   subobjects with an id of the form reserved for API attributes -
   but it seems to have got lost in the Wiki noise :-(

>  2. There will be a new interface in Zope 2.3 that will allow
>     you to prevent a name from being used lower in a containement
>     hierarchy. This change is documented at: 
>     http://dev.zope.org/Wikis/DevSite/Proposals/ReplaceableProperty.
>     The work has already been done and checked into CVS. I've asked Shane,
>     the author, to update the interfaces wiki to capture this change.


B. A common mistake in DTML authoring is to look up a name in the
   DTML namespace when the context expected to contain the name is
   not at the top of the namespace stack. The bug goes undetected
   if the context at the top of the stack does not contain that
   name.

   I have found that this happens too frequently even for
   skilled authors, and is rarely detected in review. In summary:
   one namespace isnt enough.

   I suspect that this is the problem percieved by Andrew Kuchling
   (who started this thread back on zope-zeo). Our solution
   to this (successful so far) has been to replace DTML in any use
   other than Document Templates.

   (For me, the greatest horror is the name 'DTML Method'. The name
   'method' implies a tight coupling to the instance that it is a
   method of, however it is possible for a DTML Method to execute in
   a context where all of it's instances attributes are masked by
   those of other objects. Urgh)




Toby Dickenson
tdickenson@geminidataloggers.com