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 hpk, michael.foord, ncoghlan, r.david.murray, rbcollins
Date 2014-10-23.08:20:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1414052459.87.0.824900414022.issue10548@psf.upfronthosting.co.za>
In-reply-to
Content
While I agree with Robert's comments in general, the main question to be resolved here is the scope of the "expectedFailure" decorator.

Yes, it's applied specifically to the test execution phase when writing the code, but the question is how the following scenarios should be handled when the test is marked that way:

- setUp throws an exception
- test passes, tearDown or cleanUp throw an exception
- test fails, tearDown or cleanUp throw an exception
- test throws an exception, tearDown or cleanUp throw an exception

From my perspective, those cases represent:

- error
- unexpected success OR error
- expected failure
- expected failure

If the test itself fails as expected, then I'm OK with cleanup code also failing as a consequence.

However, I'd also be OK with the simpler model that treats the decorator as covering the whole setUp/test/cleanUp/tearDown cycle, in which case an exception from *any* of those methods would be categorised as satisfying the "expected failure" decorator.
History
Date User Action Args
2014-10-23 08:20:59ncoghlansetrecipients: + ncoghlan, rbcollins, r.david.murray, michael.foord, hpk
2014-10-23 08:20:59ncoghlansetmessageid: <1414052459.87.0.824900414022.issue10548@psf.upfronthosting.co.za>
2014-10-23 08:20:59ncoghlanlinkissue10548 messages
2014-10-23 08:20:59ncoghlancreate