[Product-Developers] Re: Test setup in ZopeSkel
Ross Patterson writes: Daniel Nouri writes: Not going into the TANGLED MESS that Plone test setups have arrived to, I believe that you'll need to load your ZCML if you depend on the registrations therein in your test. That is, AFAIK, noone's going to implicitely load the site.zcml for you, which is a good thing. And yes, being able to run the tests independently of the specific buildout you're using it with is quite a feature. The PloneSite layer depends on the ZCML layer which does indeed load site.zcml. So if the ZCML your test fixture requires is included by loading site.zcml for the instance and you're using the layer PloneSite (which PloneTestCase does), then you don't need to load it explicitly in your test fixture. At least that's my understanding. :) Ugh. If that's so, I call it broken. BTW, I'm very much in favor of reducing the boilerplate in ZopeSkel, particularly the testing boilerplate. Here's the boilerplate I use for a testing.py module: I like this. Anyone against using it for our ZopeSkel templates? -- http://danielnouri.org ___ Product-Developers mailing list Product-Developers@lists.plone.org http://lists.plone.org/mailman/listinfo/product-developers
[Product-Developers] Re: Test setup in ZopeSkel
Daniel Nouri [EMAIL PROTECTED] writes: Ross Patterson writes: Daniel Nouri writes: Not going into the TANGLED MESS that Plone test setups have arrived to, I believe that you'll need to load your ZCML if you depend on the registrations therein in your test. That is, AFAIK, noone's going to implicitely load the site.zcml for you, which is a good thing. And yes, being able to run the tests independently of the specific buildout you're using it with is quite a feature. The PloneSite layer depends on the ZCML layer which does indeed load site.zcml. So if the ZCML your test fixture requires is included by loading site.zcml for the instance and you're using the layer PloneSite (which PloneTestCase does), then you don't need to load it explicitly in your test fixture. At least that's my understanding. :) Ugh. If that's so, I call it broken. Yeah, I've always thought so. Of course one problem with doing away with it that fact that a lot of tests need ZCML dependencies to be configured. I used to use include statements to include all the ZCML my code depended on, but someone informed me this was poor behavior, that stitching together packages was the job of an app, not of a package itself and shouldn't be done in tests. And if I were working in a Z3 world, where components were nicely isolated, that would work great. The boundaries between the different ZCML would nicely coincide with the mock-up I needed for my tests. In my experience, however, the assumption of isolation simply isn't true in most of my real world Plone work excepting the most pure infrastructure or framework work. Most of my tests are bastardized functional tests and it seems like this is widely the case. Of course this is because ZopeTestCase and PloneTestCase themselves are much closer to functional test fixtures than unit test fixtures. Indeed, they would break thoroughly without loading the ZCML from most of their dependencies. So maybe the ZCML layer could be changed to explicitly load just the ZCML that Plone *core* itself depends on. IOW, just enough ZCML for PTC to work. This seems like a nice incremental step forward. It eliminates the magic of your package's ZCML being included for all tests that happen to use the PloneSite layer just because your buildout includes your package in site.zcml. But it preserves the functional behavior of loading all the ZCML required by Plone. This, however, would be a very disruptive change, since many tests in the wild unwittingly depend on site.zcml being loaded and would break with minimal explanation. BTW, I'm very much in favor of reducing the boilerplate in ZopeSkel, particularly the testing boilerplate. Here's the boilerplate I use for a testing.py module: I like this. Anyone against using it for our ZopeSkel templates? I'm for it! :) Ross ___ Product-Developers mailing list Product-Developers@lists.plone.org http://lists.plone.org/mailman/listinfo/product-developers
[Product-Developers] Re: Test setup in ZopeSkel
Maurits van Rees writes: I can imagine that the lines for loading the zcml *are* needed there because then you can ensure that the zcml gets loaded before calling installPackage. Is this perhaps the only good reason for including those zcml lines in that specific case only? Not going into the TANGLED MESS that Plone test setups have arrived to, I believe that you'll need to load your ZCML if you depend on the registrations therein in your test. That is, AFAIK, noone's going to implicitely load the site.zcml for you, which is a good thing. And yes, being able to run the tests independently of the specific buildout you're using it with is quite a feature. Daniel -- http://danielnouri.org ___ Product-Developers mailing list Product-Developers@lists.plone.org http://lists.plone.org/mailman/listinfo/product-developers
[Product-Developers] Re: Test setup in ZopeSkel
Daniel Nouri [EMAIL PROTECTED]
writes:
Maurits van Rees writes:
I can imagine that the lines for loading the zcml *are* needed there
because then you can ensure that the zcml gets loaded before calling
installPackage. Is this perhaps the only good reason for including
those zcml lines in that specific case only?
Not going into the TANGLED MESS that Plone test setups have arrived to,
I believe that you'll need to load your ZCML if you depend on the
registrations therein in your test. That is, AFAIK, noone's going to
implicitely load the site.zcml for you, which is a good thing.
And yes, being able to run the tests independently of the specific
buildout you're using it with is quite a feature.
The PloneSite layer depends on the ZCML layer which does indeed load
site.zcml. So if the ZCML your test fixture requires is included by
loading site.zcml for the instance and you're using the layer PloneSite
(which PloneTestCase does), then you don't need to load it explicitly in
your test fixture. At least that's my understanding. :)
BTW, I'm very much in favor of reducing the boilerplate in ZopeSkel,
particularly the testing boilerplate. Here's the boilerplate I use for
a testing.py module:
from Testing import ZopeTestCase
from Products.PloneTestCase import ptc
from collective.testcaselayer import ptc as tcl_ptc
ptc.setupPloneSite()
class InstallLayer(tcl_ptc.BasePTCLayer):
def afterSetUp(self):
ZopeTestCase.installProduct('foo')
self.addProfile('foo:default')
install_layer = InstallLayer([ptc.PloneTestCase.layer])
Then in tests.py all I need is:
import unittest
from zope.testing import doctest
from Testing import ZopeTestCase
from Products.PloneTestCase import ptc
from foo import testing
def test_suite():
suite = ZopeTestCase.ZopeDocFileSuite(
'README.txt',
optionflags=(
doctest.NORMALIZE_WHITESPACE|
doctest.ELLIPSIS|
doctest.REPORT_NDIFF),
test_class=ptc.PloneTestCase)
suite.layer = testing.install_layer
return unittest.TestSuite([suite])
if __name__ == '__main__':
unittest.main(defaultTest='test_suite')
I find collective.testcaselayer to be really useful and has made all my
test fixtures *much* simpler and more reliable. So far, I haven't head
that it's been of much use to anyone else, so maybe it's just me. :)
But if any of you can take a look at it, try it out and give me some
feedback, that would be great.
Ross
___
Product-Developers mailing list
Product-Developers@lists.plone.org
http://lists.plone.org/mailman/listinfo/product-developers
