Zope Test Summaries 2006-04-05
[We seem to have lost Steve Alexander's test summarizer. I will contact him in a separate mail.] The switch to Python 2.3.4 caused tests for Zope 2.7 and 2.8 to experience a funny problem with the logging module. Anybody want to take a guess what's up here? I know these are not a truly "supported" configurations, but still. http://mail.zope.org/pipermail/zope-tests/2006-April/004645.html http://mail.zope.org/pipermail/zope-tests/2006-April/004647.html The VHM tests in Zope 2.9 and trunk broke last night: http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html Stefan -- Anything that happens, happens. --Douglas Adams
On Thu, Apr 06, 2006 at 10:45:11AM +0200, Stefan H. Holek wrote:
The VHM tests in Zope 2.9 and trunk broke last night:
http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html
I'm assuming this was me, but I ran test.py -q -all before checking in so I'm not sure how that happened. Investigating. -- Paul Winkler http://www.slinkp.com
--On 6. April 2006 12:06:25 -0400 Paul Winkler <pw_lists@slinkp.com> wrote:
On Thu, Apr 06, 2006 at 10:45:11AM +0200, Stefan H. Holek wrote:
The VHM tests in Zope 2.9 and trunk broke last night:
http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html
zope-tests? I've never seen that list :-) But this reminds of that I am missing mails from the buildbot....nobody broke the the trunk/branches lately? Unbelieveble :-) Andreas
On Thu, Apr 06, 2006 at 12:06:25PM -0400, Paul Winkler wrote:
On Thu, Apr 06, 2006 at 10:45:11AM +0200, Stefan H. Holek wrote:
The VHM tests in Zope 2.9 and trunk broke last night:
http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html
I'm assuming this was me, but I ran test.py -q -all before checking in so I'm not sure how that happened. Investigating.
Must've run the tests in the wrong sandbox :-\ This failure was a side-effect of the changes I made: - The unit tests in Products/Session were polluting os.environ with SERVER_NAME and SERVER_PORT keys. - The unit tests in Products/SiteAccess were relying on the old behavior of Testing.makerequest to unconditionally set those keys in the request. - My change allowed the values from the Sessions tests to show up in the SiteAccess tests. I've fixed the Sessions tests to use a dict instead of os.environ. But I'm also concerned that similarly indirect breakage might happen in other projects if they use os.environ carelessly. This part of my change was an effort to remove redundancy, not a bugfix; so on second thought, given the demonstrated potential for breakage in other test suites, it doesn't belong on the stable 2.9 branch and I'll revert that change there. But I'll leave it on the trunk. -- Paul Winkler http://www.slinkp.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Winkler wrote:
On Thu, Apr 06, 2006 at 12:06:25PM -0400, Paul Winkler wrote:
On Thu, Apr 06, 2006 at 10:45:11AM +0200, Stefan H. Holek wrote:
The VHM tests in Zope 2.9 and trunk broke last night:
http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html
I'm assuming this was me, but I ran test.py -q -all before checking in so I'm not sure how that happened. Investigating.
Must've run the tests in the wrong sandbox :-\
This failure was a side-effect of the changes I made:
- The unit tests in Products/Session were polluting os.environ with SERVER_NAME and SERVER_PORT keys.
- The unit tests in Products/SiteAccess were relying on the old behavior of Testing.makerequest to unconditionally set those keys in the request.
- My change allowed the values from the Sessions tests to show up in the SiteAccess tests.
I've fixed the Sessions tests to use a dict instead of os.environ.
But I'm also concerned that similarly indirect breakage might happen in other projects if they use os.environ carelessly.
This part of my change was an effort to remove redundancy, not a bugfix; so on second thought, given the demonstrated potential for breakage in other test suites, it doesn't belong on the stable 2.9 branch and I'll revert that change there. But I'll leave it on the trunk.
+1 for getting rid of *anything* in Testing which does something as Utterly Evil (tm) as scribbling on 'os.environ'. Any tests which break on that account should be fixed, not covered over. You don't risk breaking production code, only tests, and those *need* to be fixed, even when running against the "stable" tree (I would even think backporting to 2.8 was worthwhile, just for the testing bugs it would expose). Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENZBb+gerLs4ltQ4RAntpAJ9iRnL8zZPMtaNGrQrKxAhxD7L7JgCgmC3O K/mIjFr++qV6xpo2L+x60vg= =1xn+ -----END PGP SIGNATURE-----
On Thu, Apr 06, 2006 at 06:04:11PM -0400, Tres Seaver wrote:
+1 for getting rid of *anything* in Testing which does something as Utterly Evil (tm) as scribbling on 'os.environ'.
Any tests which break on that account should be fixed, not covered over. You don't risk breaking production code, only tests, and those *need* to be fixed, even when running against the "stable" tree (I would even think backporting to 2.8 was worthwhile, just for the testing bugs it would expose).
I agree with the sentiment, but thinking of it from a user's p.o.v. I would be mighty annoyed if I upgraded from 2.9.2 and 2.9.3 and found that tests in package foo were broken by tests in package bar only because of changes in package qux. Test pollution bugs can be real maddening time-wasters. Upgrading to 2.10 is another story ;-) I may try eradicating os.environ usage from Testing on my trunk sandbox and see what else breaks... -- Paul Winkler http://www.slinkp.com
On Fri, Apr 07, 2006 at 10:04:36AM -0400, Paul Winkler wrote:
I may try eradicating os.environ usage from Testing on my trunk sandbox and see what else breaks...
Answer: nothing. Committed on the trunk. I did a bit of grepping around too. There are a few tests that twiddle os.environ, but these are all things that really rely on environ. For example, the tests for zdaemon/tests/testzdoptions.py, which uses a little monkeypatching in setUp() and unpatching in tearDown() so the environ should be restored after every test. However, there are some tests around that scribble on the REQUEST.environ as created by Testing.makerequest. So these would have inadvertently twiddled the real os.environ before my latest commit. The test authors might not even know they were doing that. Blech. Fixed :) -- Paul Winkler http://www.slinkp.com
On Fri, Apr 07, 2006 at 12:52:29PM -0400, Paul Winkler wrote:
On Fri, Apr 07, 2006 at 10:04:36AM -0400, Paul Winkler wrote:
I may try eradicating os.environ usage from Testing on my trunk sandbox and see what else breaks...
Answer: nothing. Committed on the trunk.
To clarify, I just removed os.environ from Testing.makerequest. I didn't touch anything in Testing.ZopeTestCase. There's a bunch of os.environ usage in there and I'm not up for looking through that right now. -- Paul Winkler http://www.slinkp.com
participants (4)
-
Andreas Jung -
Paul Winkler -
Stefan H. Holek -
Tres Seaver