[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
Tres Seaver wrote: Jens Vagelpohl wrote: I'm still -1 on merging the branch as it is and Stefan confirmed that PortalTestCase should not be used directly: http:// mail.zope.org/pipermail/zope-cmf/2005-September/022932.html Lets work on replacing the PortalTestCase in Testing.ZopeTestCase with a abstract 'SiteTestCase' in CMFCore.tests.base.testcase, and a concrete 'DefaultSiteTestCase' someplace like CMFDefault.tests.common. We can then have Stefan follow through with deprecating PTC in Zope 2.8, and removing it in 2.9. In the meanwhile, for backward compatibility, we might need to be willing to monkey patch Testing.ZopeTestCase.PortalTestCase, if it is present, to use our new version. How about a compromise: I'll spend a little time tomorrow rewriting that test module so it does not use ZopeTestCase at all. Excellent. Another option would be to move the test into CMFDefault, where it might be appropriate to use 'DefaultSiteTestCase'. The changes on this branch are good and valuable, and a final decision and implementation of the extended testing fixtures problem will probably take a while... I'd really like to second Jens here. Geoff's contribution here is a real win, and only incidentally provoked this rather extended wrangle about how to do the testing properly. At least in part, this wrangle has been useful, as it is forcing us to think hard about how we manage our dependencies; we've been doing that informally, (but have messed up, too) but don't have any writeup of the "Right Way" to write and run tests within the various pieces of the CMF. If we are going to expand participation (e.g., to welcome contributions from Plone folks), we need to be careful that we set and keep the tone with which we receive those contributions appropriate. Writing up the "developer's crib sheet" would help, so that we had something objective describing how we do development; focusing on encouraging / fostering new CMF developers will help, too. Keeping the discussion positive is something we can all do to make the community more welcoming. +1 for everything And a big applause for Geoff and Jens! Their joined effort made CachingPolicyManager and the CMF a better piece of software. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
Here's the result of my refactoring/rewriting for the tests in question: http://svn.zope.org/CMF/branches/geoffd-cachingpolicymanager-branch/? rev=38439&view=rev Geoff, as the one with the most "domain knowledge" as far as the code changes go, could you check the tests (and especially the comments I have added) to make sure they make sense? Flames welcome from everyone else as well, of course ;) jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: >> I'm still -1 on merging the branch as it is and Stefan confirmed that >> PortalTestCase should not be used directly: http:// >> mail.zope.org/pipermail/zope-cmf/2005-September/022932.html Lets work on replacing the PortalTestCase in Testing.ZopeTestCase with a abstract 'SiteTestCase' in CMFCore.tests.base.testcase, and a concrete 'DefaultSiteTestCase' someplace like CMFDefault.tests.common. We can then have Stefan follow through with deprecating PTC in Zope 2.8, and removing it in 2.9. In the meanwhile, for backward compatibility, we might need to be willing to monkey patch Testing.ZopeTestCase.PortalTestCase, if it is present, to use our new version. > How about a compromise: I'll spend a little time tomorrow rewriting > that test module so it does not use ZopeTestCase at all. Excellent. Another option would be to move the test into CMFDefault, where it might be appropriate to use 'DefaultSiteTestCase'. > The changes on this branch are good and valuable, and a final decision > and implementation of the extended testing fixtures problem will > probably take a while... I'd really like to second Jens here. Geoff's contribution here is a real win, and only incidentally provoked this rather extended wrangle about how to do the testing properly. At least in part, this wrangle has been useful, as it is forcing us to think hard about how we manage our dependencies; we've been doing that informally, (but have messed up, too) but don't have any writeup of the "Right Way" to write and run tests within the various pieces of the CMF. If we are going to expand participation (e.g., to welcome contributions from Plone folks), we need to be careful that we set and keep the tone with which we receive those contributions appropriate. Writing up the "developer's crib sheet" would help, so that we had something objective describing how we do development; focusing on encouraging / fostering new CMF developers will help, too. Keeping the discussion positive is something we can all do to make the community more welcoming. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDIbex+gerLs4ltQ4RAobkAKDbA026qEp8Axp1K/Kv4HL4CeBCNgCg2Ngl cmSdwU0oCHZOzwacuG7zfDg= =2MPH -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
On Fri, Sep 09, 2005 at 04:33:48PM +0100, Jens Vagelpohl wrote: | >I'm still -1 on merging the branch as it is and Stefan confirmed | >that PortalTestCase should not be used directly: http:// | >mail.zope.org/pipermail/zope-cmf/2005-September/022932.html | | How about a compromise: I'll spend a little time tomorrow rewriting | that test module so it does not use ZopeTestCase at all. | | The changes on this branch are good and valuable, and a final | decision and implementation of the extended testing fixtures problem | will probably take a while... I compromise in backporting your changes to 1.4 branch. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
On 9 Sep 2005, at 15:10, yuppie wrote: Geoff Davis wrote: On Fri, 09 Sep 2005 11:33:53 +0200, yuppie wrote: Are you aware of the fact that test_Template304Handling.py depends on PortalTestCase? Do you plan to change that before merging your branch? Yes, I am aware of that fact. No, I am not planning to change it -- it works just fine. I am sure that if the CMF changes as substantially as you are worried about, there will be numerous things that will need to change. I'm not sure that it is time well spent trying to fix things that may or may not happen at some unspecified point in the future. However, if you feel sufficiently strongly about it, the code is in SVN and you are more than welcome to work on it. I'm still -1 on merging the branch as it is and Stefan confirmed that PortalTestCase should not be used directly: http:// mail.zope.org/pipermail/zope-cmf/2005-September/022932.html How about a compromise: I'll spend a little time tomorrow rewriting that test module so it does not use ZopeTestCase at all. The changes on this branch are good and valuable, and a final decision and implementation of the extended testing fixtures problem will probably take a while... jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
On Fri, 2005-09-09 at 16:10 +0200, yuppie wrote: > I'm still -1 on merging the branch as it is and Stefan confirmed that > PortalTestCase should not be used directly: > http://mail.zope.org/pipermail/zope-cmf/2005-September/022932.html Yes, Stefan and I are saying the same thing: the Right Way to do this is to implement a CMFDefaultTestCase that subclasses PortalTestCase. In fact, there is already such a test case in the Plone collective, and Stefan has talked about cleaning it up after the Plone Conference for inclusion in the CMF. It should be trivial to change the test once this happens. Just so you know, the method in PortalTestCase that should be abstract is getPortal. If you take a look at the test in question, you will see that (1) it does implement a subclass of PortalTestCase, and (2) that it does implement the method getPortal. That's why the test actually works ;) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
Geoff Davis wrote: On Fri, 09 Sep 2005 11:33:53 +0200, yuppie wrote: Are you aware of the fact that test_Template304Handling.py depends on PortalTestCase? Do you plan to change that before merging your branch? Yes, I am aware of that fact. No, I am not planning to change it -- it works just fine. I am sure that if the CMF changes as substantially as you are worried about, there will be numerous things that will need to change. I'm not sure that it is time well spent trying to fix things that may or may not happen at some unspecified point in the future. However, if you feel sufficiently strongly about it, the code is in SVN and you are more than welcome to work on it. I'm still -1 on merging the branch as it is and Stefan confirmed that PortalTestCase should not be used directly: http://mail.zope.org/pipermail/zope-cmf/2005-September/022932.html But I don't have to decide about that so I'll shut up now. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
On Fri, 09 Sep 2005 11:33:53 +0200, yuppie wrote: >> Perhaps I wasn't clear earlier when I said that I thought we should ship >> our own CMFDefaultTestCase with the CMF? If I am understanding you >> correctly, shipping a CMF-specific CMFDefaultTestCase should address your >> dependency concerns. > > ??? > > Are you aware of the fact that test_Template304Handling.py depends on > PortalTestCase? Do you plan to change that before merging your branch? Yes, I am aware of that fact. No, I am not planning to change it -- it works just fine. I am sure that if the CMF changes as substantially as you are worried about, there will be numerous things that will need to change. I'm not sure that it is time well spent trying to fix things that may or may not happen at some unspecified point in the future. However, if you feel sufficiently strongly about it, the code is in SVN and you are more than welcome to work on it. I think the right way to move forward is to develop a CMFDefaultTestCase, but unfortunately, I don't have time to work on that right now. Geoff ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
yuppie wrote: - Even with your workaround the tests are failing if run together with CMFCalendar tests. Looks like the skin changes in CalendarRequestTests.setUp are not cleaned up correctly. Just checked in a fix for this. (1.5 branch and trunk) Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
Hi Geoff! Geoff Davis wrote: On Thu, 08 Sep 2005 19:24:51 +0200, yuppie wrote: Knock! Knock! Anybody there? I told you twice that I'm concerned about using PortalTestCase: http://mail.zope.org/pipermail/zope-cmf/2005-September/022891.html Would be nice to get some feedback. Obviously you don't share those concerns. What do you propose to do if changes in CMF make a new version of PortalTestCase necessary? [...] Perhaps I wasn't clear earlier when I said that I thought we should ship our own CMFDefaultTestCase with the CMF? If I am understanding you correctly, shipping a CMF-specific CMFDefaultTestCase should address your dependency concerns. ??? Are you aware of the fact that test_Template304Handling.py depends on PortalTestCase? Do you plan to change that before merging your branch? One other frustration: I was able to run my new tests in isolation, but when I ran the whole test suite, they failed. The problem appears to be that somehow some things that happen in test_ActionProviderBase.py are not being cleaned up before test_Template304Handling.py. Some items placed in the CMFSetup profile registry in test_ActionProviderBase.py are still present when test_Template304Handling.py runs. I added a workaround that clears out profile_registry, but that shouldn't be necessary. I don't know if the problem is with the test runner or with test_ActionProviderBase.py, but it's definitely bad that state from one test is affecting another. This problem appeared in both Zope 2.7.7 and Zope 2.8.1. I guess ZopeTestCase installs again products that are already installed. The registry raises errors if the same product is registered twice. Not sure how to resolve this. I believe that ZopeTestCase has some way of avoiding double imports since we have big test suites in Plone that all do their own imports. I don't know the details, but perhaps Stefan Holek would? I am not so sure it is a ZopeTestCase specific problem -- perhaps things have been running fine to date only because test_ActionProviderBase.py is the only test that does these kinds of imports. Two observations: - The traceback in http://mail.zope.org/pipermail/zope-cmf/2005-September/022933.html shows that products *are* installed twice. This has nothing to do with a specific test like test_ActionProviderBase.py. This seems to be a general problem with running ZopeTestCase tests and other tests side by side. - Even with your workaround the tests are failing if run together with CMFCalendar tests. Looks like the skin changes in CalendarRequestTests.setUp are not cleaned up correctly. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: Sane checkin mail delivery (was: Re: [Zope-CMF] Re: CachingPolicyManager improvements checked in to svn)
Dieter Maurer wrote: > Someone making occational changes may not be interested > to be informed about all the modifications going on. +1. -PW ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
Sidnei da Silva wrote: | The z3interfaces tests are based on the assumption that Five is | available if zope.interface is available. Five creates IActionInfo | dynamically on startup. | | That's obviously not true in your setup. Looking again at these tests it | would be more robust to include the interface imports in the try/except | ImportError statement. For the records, I had other tests failing for the same reason in PAS. It's common to have zope.interface but not five if you install twisted in Ubuntu it has a dependency on the python-zope-interface package or something. Ok. I'll change those tests. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
On Thu, 08 Sep 2005 19:24:51 +0200, yuppie wrote: > Knock! Knock! Anybody there? > > I told you twice that I'm concerned about using PortalTestCase: > http://mail.zope.org/pipermail/zope-cmf/2005-September/022891.html > > Would be nice to get some feedback. Obviously you don't share those > concerns. What do you propose to do if changes in CMF make a new version > of PortalTestCase necessary? > > Florent also raised (different) concerns about using PortalTestCase: > http://mail.zope.org/pipermail/zope-cmf/2005-September/022917.html Perhaps I wasn't clear earlier when I said that I thought we should ship our own CMFDefaultTestCase with the CMF? If I am understanding you correctly, shipping a CMF-specific CMFDefaultTestCase should address your dependency concerns. RE Florian's comment, CMFDefaultTestCase would be for use in situations that require that a full portal be instantiated; for other use cases, use something else. I personally don't think speed is all that important in unit tests. > That's obviously not true in your setup. Looking again at these tests it > would be more robust to include the interface imports in the try/except > ImportError statement. So I would imagine that the same arguments about tests behaving without additional products being installed would apply to Five as well as to ZopeTestCase ;) >> One other frustration: I was able to run my new tests in isolation, but >> when I ran the whole test suite, they failed. The problem appears to be >> that somehow some things that happen in test_ActionProviderBase.py are not >> being cleaned up before test_Template304Handling.py. Some items placed in >> the CMFSetup profile registry in test_ActionProviderBase.py are still >> present when test_Template304Handling.py runs. I added a workaround that >> clears out profile_registry, but that shouldn't be necessary. I don't >> know if the problem is with the test runner or with >> test_ActionProviderBase.py, but it's definitely bad that state from one >> test is affecting another. This problem appeared in both Zope 2.7.7 and >> Zope 2.8.1. > > I guess ZopeTestCase installs again products that are already installed. > The registry raises errors if the same product is registered twice. > > Not sure how to resolve this. I believe that ZopeTestCase has some way of avoiding double imports since we have big test suites in Plone that all do their own imports. I don't know the details, but perhaps Stefan Holek would? I am not so sure it is a ZopeTestCase specific problem -- perhaps things have been running fine to date only because test_ActionProviderBase.py is the only test that does these kinds of imports. Geoff ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
| The z3interfaces tests are based on the assumption that Five is | available if zope.interface is available. Five creates IActionInfo | dynamically on startup. | | That's obviously not true in your setup. Looking again at these tests it | would be more robust to include the interface imports in the try/except | ImportError statement. For the records, I had other tests failing for the same reason in PAS. It's common to have zope.interface but not five if you install twisted in Ubuntu it has a dependency on the python-zope-interface package or something. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Sane checkin mail delivery (was: Re: [Zope-CMF] Re: CachingPolicyManager improvements checked in to svn)
Jens Vagelpohl wrote at 2005-9-8 11:41 +0100: > >On 8 Sep 2005, at 11:08, yuppie wrote: > ... >Geoff, can you double- >check that the email address you have in your zope.org membership is >correct and then subscribe to the cmf-checkins list? That should make >any further check-in messages appear for us. I have seen such a wish several times. Would it not be more sane to fix the checkin mail delivery such that it does not require the checking in person to have a subscription? Someone making occational changes may not be interested to be informed about all the modifications going on. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
Hi Geoff! Geoff Davis wrote: On Thu, 08 Sep 2005 12:08:23 +0200, yuppie wrote: - Tests are easier to find and maintain if they are located in test_.py. Most CMF tests follow that pattern. Yes, I put the tests relating to new CachingPolicyManager functionality into test_CachingPolicyManager.py. The other tests I added were integration tests that check how CachingPolicyManager interacts with FSPageTemplate.py. I didn't really think those tests were appropriate for either test_CachingPolicyManager.py or test_FSPageTemplate.py. Instead I put them in test_Template304Handling.py, and I tried to convey the functionality being tested in the file name. I'm open to other naming suggestions, though. Ok. I see your point. In the first place those tests seem to test CachingPolicyManager features, so I would have added them to test_CachingPolicyManager.py. But maybe that's just me. PS Those of you who raised concerns about ZopeTestCase causing test problems in Zope 2.7 might want to take a look at why test_z3interfaces is broken when you run the tests with zopectl test. 2.) Please note that I raised concerns about using PortalTestCase. Knock! Knock! Anybody there? I told you twice that I'm concerned about using PortalTestCase: http://mail.zope.org/pipermail/zope-cmf/2005-September/022891.html Would be nice to get some feedback. Obviously you don't share those concerns. What do you propose to do if changes in CMF make a new version of PortalTestCase necessary? Florent also raised (different) concerns about using PortalTestCase: http://mail.zope.org/pipermail/zope-cmf/2005-September/022917.html 3.) Please be more specific. I can't reproduce any problems with test_z3interfaces. Yeah, sorry to sound cranky here -- I'm in the middle of a nasty deployment. Accepted. I put in some effort getting my tests to degrade quietly for Zope 2.7 only to find some other Zope 2.7 problems with the tests. It could be it's my setup, though -- I'm not sure. When running the tests with a fresh checkout of the 1.5 branch on Zope 2.7.7 using bin/zopectl test --dir Products/CMFCore/tests I get a bunch of errors like the following: == ERROR: test_z3interfaces (CMFCore.tests.test_ActionInformation.ActionInfoTests) -- Traceback (most recent call last): File "/home/zope/plonedev/Products/CMFCore/tests/test_ActionInformation.py", line 60, in test_z3interfaces from Products.CMFCore.interfaces import IActionInfo ImportError: cannot import name IActionInfo I don't see IActionInfo defined anywhere in interfaces, so I don't think it's just me. The z3interfaces tests are based on the assumption that Five is available if zope.interface is available. Five creates IActionInfo dynamically on startup. That's obviously not true in your setup. Looking again at these tests it would be more robust to include the interface imports in the try/except ImportError statement. One other frustration: I was able to run my new tests in isolation, but when I ran the whole test suite, they failed. The problem appears to be that somehow some things that happen in test_ActionProviderBase.py are not being cleaned up before test_Template304Handling.py. Some items placed in the CMFSetup profile registry in test_ActionProviderBase.py are still present when test_Template304Handling.py runs. I added a workaround that clears out profile_registry, but that shouldn't be necessary. I don't know if the problem is with the test runner or with test_ActionProviderBase.py, but it's definitely bad that state from one test is affecting another. This problem appeared in both Zope 2.7.7 and Zope 2.8.1. I guess ZopeTestCase installs again products that are already installed. The registry raises errors if the same product is registered twice. Not sure how to resolve this. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
On 8 Sep 2005, at 16:48, Geoff Davis wrote: bin/zopectl test --dir Products/CMFCore/tests I get a bunch of errors like the following: == ERROR: test_z3interfaces (CMFCore.tests.test_ActionInformation.ActionInfoTests) -- Traceback (most recent call last): File "/home/zope/plonedev/Products/CMFCore/tests/ test_ActionInformation.py", line 60, in test_z3interfaces from Products.CMFCore.interfaces import IActionInfo ImportError: cannot import name IActionInfo I don't see IActionInfo defined anywhere in interfaces, so I don't think it's just me. All those tests run fine for me using your branch and a vanilla Zope 2.7.6. I'd make a wild guess and say it's your setup. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
On Thu, 08 Sep 2005 12:08:23 +0200, yuppie wrote: > - Please make sure your checkins show up on the CMF-checkins list. Don't > know if Tres can fix that for you or if you've got to register for that > list. Ok, I will look into it. > - Please don't forget to set svn:eol-style and svn:keywords Id for new > files. D'oh -- I forgot those. > - Tests are easier to find and maintain if they are located in > test_.py. Most CMF tests follow that pattern. Yes, I put the tests relating to new CachingPolicyManager functionality into test_CachingPolicyManager.py. The other tests I added were integration tests that check how CachingPolicyManager interacts with FSPageTemplate.py. I didn't really think those tests were appropriate for either test_CachingPolicyManager.py or test_FSPageTemplate.py. Instead I put them in test_Template304Handling.py, and I tried to convey the functionality being tested in the file name. I'm open to other naming suggestions, though. >> PS Those of you who raised concerns about ZopeTestCase causing test >> problems in Zope 2.7 might want to take a look at why test_z3interfaces is >> broken when you run the tests with zopectl test. > > 1.) Why "those of you who raised concerns about ZopeTestCase"? > > 2.) Please note that I raised concerns about using PortalTestCase. > > 3.) Please be more specific. I can't reproduce any problems with > test_z3interfaces. Yeah, sorry to sound cranky here -- I'm in the middle of a nasty deployment. I put in some effort getting my tests to degrade quietly for Zope 2.7 only to find some other Zope 2.7 problems with the tests. It could be it's my setup, though -- I'm not sure. When running the tests with a fresh checkout of the 1.5 branch on Zope 2.7.7 using bin/zopectl test --dir Products/CMFCore/tests I get a bunch of errors like the following: == ERROR: test_z3interfaces (CMFCore.tests.test_ActionInformation.ActionInfoTests) -- Traceback (most recent call last): File "/home/zope/plonedev/Products/CMFCore/tests/test_ActionInformation.py", line 60, in test_z3interfaces from Products.CMFCore.interfaces import IActionInfo ImportError: cannot import name IActionInfo I don't see IActionInfo defined anywhere in interfaces, so I don't think it's just me. One other frustration: I was able to run my new tests in isolation, but when I ran the whole test suite, they failed. The problem appears to be that somehow some things that happen in test_ActionProviderBase.py are not being cleaned up before test_Template304Handling.py. Some items placed in the CMFSetup profile registry in test_ActionProviderBase.py are still present when test_Template304Handling.py runs. I added a workaround that clears out profile_registry, but that shouldn't be necessary. I don't know if the problem is with the test runner or with test_ActionProviderBase.py, but it's definitely bad that state from one test is affecting another. This problem appeared in both Zope 2.7.7 and Zope 2.8.1. Geoff ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
On 8 Sep 2005, at 12:00, yuppie wrote: PS Those of you who raised concerns about ZopeTestCase causing test problems in Zope 2.7 might want to take a look at why test_z3interfaces is broken when you run the tests with zopectl test. 1.) Why "those of you who raised concerns about ZopeTestCase"? I raised a concern that Zope 2.7 does not come with ZopeTestCase, so the test that uses it should not raise an error or failure condition. There should not be any failures when you download a vanilla Zope 2.7.x and CMF 1.5.x and run the unit tests, unless there is a real software bug. I know. My question wasn't *who* those people are but *why* it is more likely that those people might want to take a look at the test_z3interfaces issue. Right, Geoff, back to you then ;) jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
Jens Vagelpohl wrote: On 8 Sep 2005, at 11:08, yuppie wrote: PS Those of you who raised concerns about ZopeTestCase causing test problems in Zope 2.7 might want to take a look at why test_z3interfaces is broken when you run the tests with zopectl test. 1.) Why "those of you who raised concerns about ZopeTestCase"? I raised a concern that Zope 2.7 does not come with ZopeTestCase, so the test that uses it should not raise an error or failure condition. There should not be any failures when you download a vanilla Zope 2.7.x and CMF 1.5.x and run the unit tests, unless there is a real software bug. I know. My question wasn't *who* those people are but *why* it is more likely that those people might want to take a look at the test_z3interfaces issue. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
On 8 Sep 2005, at 11:08, yuppie wrote: - Please make sure your checkins show up on the CMF-checkins list. Don't know if Tres can fix that for you or if you've got to register for that list. I was wondering why I did not get any mail... Geoff, can you double- check that the email address you have in your zope.org membership is correct and then subscribe to the cmf-checkins list? That should make any further check-in messages appear for us. PS Those of you who raised concerns about ZopeTestCase causing test problems in Zope 2.7 might want to take a look at why test_z3interfaces is broken when you run the tests with zopectl test. 1.) Why "those of you who raised concerns about ZopeTestCase"? I raised a concern that Zope 2.7 does not come with ZopeTestCase, so the test that uses it should not raise an error or failure condition. There should not be any failures when you download a vanilla Zope 2.7.x and CMF 1.5.x and run the unit tests, unless there is a real software bug. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn
Hi Geoff! Geoff Davis wrote: I have checked my CachingPolicyManager improvements into the geoffd-cachingpolicymanager-branch. Enjoy! Great! Some feedback regard formal aspects: - Please make sure your checkins show up on the CMF-checkins list. Don't know if Tres can fix that for you or if you've got to register for that list. - Please don't forget to set svn:eol-style and svn:keywords Id for new files. - Tests are easier to find and maintain if they are located in test_.py. Most CMF tests follow that pattern. PS Those of you who raised concerns about ZopeTestCase causing test problems in Zope 2.7 might want to take a look at why test_z3interfaces is broken when you run the tests with zopectl test. 1.) Why "those of you who raised concerns about ZopeTestCase"? 2.) Please note that I raised concerns about using PortalTestCase. 3.) Please be more specific. I can't reproduce any problems with test_z3interfaces. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
