More on Layers
Riding Off into the Layered Sunset
ZopeTestCase still needs to grow up. Depending on code execution by import is pretty evil and forces developers to make choices that severely limit the ability of a framework to adapt to change(like say....adding zope3 component architecture to the mix). Controlling the exact order of import when dealing with code outside of your control is near impossible. The longer this remains as such, the more the engineering debt compounds and the worse someone will get hurt.
In other words, do you want me to have to break your tests again and again? Probably not.
Does ZopeTestCase have to die? Maybe not. Maybe just get it's act in line with the current state of affairs.
Following PhiliKON's suggestion that ZopeTestCase should have it's own layer that handled installProduct calls, I did some preliminary investigation into what it would take to put the entire plone stack's testing onto layers including all of ZopeTestCase. The applied initial fruits of that investigation is the stop gap measure described in the last post.
The complete work in progress is available at the following locations and goes much deeper into using layers to simplify the test structure:
The PTC layer inherits from the ZTC one and therefore all plone tests run as a section of the zope test case layer.
The majority of the tests run without issue and most issues can be fixed with by removing code. More people need to bang on it, but it's ready to be banged on.
Please bang away and let me know(or continue the work. would love some help here). With some feedback, this could get into Zope 2.11(only 3 months off).
Finally, a big shout out to Stefan Holek. Without ZopeTestCase(and stefan to impress upon people the proper way to use it), many of us might still be rubbing rocks together in a dark cave, sacrificing hours to the zope gods hitting reload.
Like many things in this world of code (like Zope2, AT, CMFFormController, etc), if it didn't work so well for so long we wouldn't be here to bitch about it now.
-w
ZopeTestCase still needs to grow up. Depending on code execution by import is pretty evil and forces developers to make choices that severely limit the ability of a framework to adapt to change(like say....adding zope3 component architecture to the mix). Controlling the exact order of import when dealing with code outside of your control is near impossible. The longer this remains as such, the more the engineering debt compounds and the worse someone will get hurt.
In other words, do you want me to have to break your tests again and again? Probably not.
Does ZopeTestCase have to die? Maybe not. Maybe just get it's act in line with the current state of affairs.
Following PhiliKON's suggestion that ZopeTestCase should have it's own layer that handled installProduct calls, I did some preliminary investigation into what it would take to put the entire plone stack's testing onto layers including all of ZopeTestCase. The applied initial fruits of that investigation is the stop gap measure described in the last post.
The complete work in progress is available at the following locations and goes much deeper into using layers to simplify the test structure:
- Zope 2.9 (layer enabled ZTC and Five)
- Zope 2.10 (layer enable ZTC and Five)
- Plone 2.1 for z2.9 (w/ all dependencies layer enabled and layer enable Five)
The PTC layer inherits from the ZTC one and therefore all plone tests run as a section of the zope test case layer.
The majority of the tests run without issue and most issues can be fixed with by removing code. More people need to bang on it, but it's ready to be banged on.
Please bang away and let me know(or continue the work. would love some help here). With some feedback, this could get into Zope 2.11(only 3 months off).
Finally, a big shout out to Stefan Holek. Without ZopeTestCase(and stefan to impress upon people the proper way to use it), many of us might still be rubbing rocks together in a dark cave, sacrificing hours to the zope gods hitting reload.
Like many things in this world of code (like Zope2, AT, CMFFormController, etc), if it didn't work so well for so long we wouldn't be here to bitch about it now.
-w
posted by whit at 12:11 AM
2 Comments:
Thank you Whit!
This is important stuff, thanks for running with it.
One question - why are the layers done as old-style classes rather than new-style ones?
I just feel a bit naked when I see
class Foo:
and I feel compelled to insert (object).
thanks!
The answer to the question about old style classes is "I'm not sure exactly". We should ask Jim Fulton. What I do know is that the testrunner has issues when it tries to introspect the bases of new style classes to build up layers.
The old style class is being used as a data structure itself rather than the description of a data structure and apparently some subtlties of classic classes are depended upon. I imagine this will change to support new style classes as we move into the future.
Post a Comment
<< Home