[z3-five] maintaining the tests
Martijn Faassen
faassen at infrae.com
Tue Jun 22 11:07:40 MEST 2004
Hi there,
Like the rest of Five, I'd like to keep the test code clean. This means
a minimum of duplication of code, hard-to-understand code, or code that
for some reason or other doesn't follow the pattern of the rest.
For this reason, I've factored out the cruft that was at the top of both
test files already to find a prefix needed to apparently find zope.conf
in some circumstances away into a zopeconf.py module. The tests don't
need to trigger this manually anymore; framework.py takes care of it.
This moves a lot of imports and hairy looking code into a more palatable
place -- out of the way of the writer or reader of the tests.
Five, like Zope 3, is a member of the Society for the Prevention of
Cruelty to Chickens, so like Zope 3, we'd like to keep to a minimum of
dead chickens. If they are needed, let's bury them in a safe place,
where they can't be copied all over the place.
This leads to another question -- test_security is definity not the
easiest thing to read. One instance of this is that for some reason
doesn't follow the standard ZopeTestCase pattern, and overrides setUp()
and tearDown() instead of using afterSetUp() and beforeTearDown(). It
also mixes in CleanUp. I tried to remove it to bring it to the
ZopeTestCase pattern, but of course I couldn't get things to work.
I'd like some comments in the code as to why there was a choice to
deviate from the standard pattern. I suspect all this work is done to
somehow cleaning up the state of the ZCML processor, as ZCML is not
built to be actually read in multiple times during the execution of a
program. I also suspect that if we make a separate product to support
the security tests, along the lines of the way test_five does it, we
don't need this special casing.
Regards,
Martijn
More information about the z3-five
mailing list