This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients baikie, brett.cannon, michael.foord, ncoghlan, ned.deily
Date 2011-09-18.11:35:05
SpamBayes Score 3.0299324e-10
Marked as misclassified No
Message-id <1316345706.69.0.994945026618.issue12958@psf.upfronthosting.co.za>
In-reply-to
Content
OK, I've now looked into *why* the socket tests are throwing errors in tearDown, and it has to do with the way the threaded client/server tests in test_socket are set up.

Specifically, ThreadableTest uses tearDown to reraise any exception raised in the client thread, and these are therefore outside the scope of the "expectedFailure" suppression in unittest.

Now that I've tracked this down, it would be fairly straightforward to fix this specifically within test_socket.ThreadableTest by appropriately adjusting the definition of ThreadableTest.clientRun to discard exceptions encountered in tests flagged as expected failures.

However, I'm wondering if that's the right thing to do. Perhaps it would make more sense to change unittest itself so that "expectedFailure" also suppresses tearDown errors. It doesn't seem all that unusual for a known failing test to also cause problems for the tearDown code.

Added Michael to the nosy list to ask for his advice/opinion. In the meantime, I'll work on a patch that adjusts ThreadableTest directly.
History
Date User Action Args
2011-09-18 11:35:06ncoghlansetrecipients: + ncoghlan, brett.cannon, baikie, ned.deily, michael.foord
2011-09-18 11:35:06ncoghlansetmessageid: <1316345706.69.0.994945026618.issue12958@psf.upfronthosting.co.za>
2011-09-18 11:35:06ncoghlanlinkissue12958 messages
2011-09-18 11:35:05ncoghlancreate