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 michael.foord
Recipients hpk, michael.foord, r.david.murray
Date 2010-12-06.23:53:48
SpamBayes Score 6.988299e-13
Marked as misclassified No
Message-id <1291679631.79.0.0979994059849.issue10548@psf.upfronthosting.co.za>
In-reply-to
Content
(made slightly redundant by Holger's comment but I'll continue anyway)

I think the issue is that setUp / tearDown are used for two different purposes.

The first is setting up and tearing down test infrastructure - where you do want to see to errors.

The other is for asserting pre and post conditions. If these are expected to fail (for whatever reason) then it may be perfectly reasonable to mark them as expectedFailure.

The fact that it was reported as a bug, and also that Antoine has requested being able to skip in a tear down (separate issue) shows that people are doing this.

So on the one hand - a small proportion of tests are marked expectedFailure and a very small subset of those might have a test infrastructure setup error. On the other hand for people who want setUp to test pre-conditions and want expectedFailure to work here will be completely unable to do this. It seems like not having consistent behaviour for expectedFailure will be more of a problem for those who want it than having it would be for those who don't need it.

As expectedFailure is not intended to be widely used anyway I would rather have consistency. It also allows the implementation to be simplified by unifying skip / expected fail / exception handling for all of setUp / tearDown / testMethod / cleanUp.
History
Date User Action Args
2010-12-06 23:53:51michael.foordsetrecipients: + michael.foord, r.david.murray, hpk
2010-12-06 23:53:51michael.foordsetmessageid: <1291679631.79.0.0979994059849.issue10548@psf.upfronthosting.co.za>
2010-12-06 23:53:48michael.foordlinkissue10548 messages
2010-12-06 23:53:48michael.foordcreate