Note that this conversation hasn't had anything to do
with ZEO for some time, so I'm moving it over to zope-dev.
Toby Dickenson wrote:
(snip)
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.
This sounds like a bug that needs to be fixed, not a limitation in the
approach. Would you mind submitting a collector item on it?
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).
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.
(snip)
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.
I think that ZPublisher.Test provides a pretty good test harness
for anything below the publisher level, such as ZCatalog.
(snip)
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?
First, as an aside, you can't prove that non-trivial software
is correct via testing. :)
Second, part of a test is deciding what the interface to the tested
software is. One way to limit the scope of testing is to limit the
promises made, for example to leave the behavior undefined under
some circumstances.
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
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 have been a couple of recent developments that I think could
help this:
1. It's much easier than it used to be to name objects using
physical paths and converting the physical paths to objects.
This would allow you to refer to a particular object using an
absolute reference.
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.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
Technical Director (888) 344-4332http://www.python.org
Digital Creationshttp://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.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
