[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