[Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 (original) (raw)

Scott David Daniels Scott.Daniels at Acm.Org
Sat Jan 14 15:17:55 CET 2006

Fred L. Drake, Jr. wrote:

Scott David Daniels wrote: > Would "expectfail", "expectfailure", "expectedfail", or > "expectedfailure", work for you?

None of these use the same naming convention as the other unittest object attributes. Perhaps something like failureExpected? I'd definately prefer something that reads cleanly; mirroring the exact form of the word "fail" doesn't make sense; making it readable does.

Hmmm.... I'd like to avoid anything looking like "failIf" or whatever (I'm afraid it will be attempted as a method), but the point about matching styles does make sense. I see my idea of XXX has inspired a huge groundswell of "no comment" yet. How about:

 @expectFailure('some reason for the failure')
 def test_whatever(self): ...

Nick Coghlan (on the recipe) wrote:

While embedding the 'or' in the except clause header is cute, its also a little subtle and obscure, and causes the check to be executed every time the test is run, rather than when the test is defined.

I wasn't striving for cute or clever there. I did want the pick up of TestCase.failureException to occur at test time, however. My reasoning is that failureException became a class variable for a reason, and test running frameworks other than unittest.main might well be stomping their own exception in there. Certainly the "failIf" methods all raise whatever exception is stored as a class variable of TestCase.

Do we want to include the equivalent of find_broken_tests(module) in unittest or is leaving it in the recipe for report writers better? I suppose it wants a better name as well. findExpectedFailures(module)? I'm off to see family, I'll check back end of next week.

--Scott David Daniels Scott.Daniels at Acm.Org

More information about the Python-Dev mailing list