[Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

[Scott David Daniels]

Fred L. Drake, Jr. wrote:
> Scott David Daniels wrote:
>  > Would "expect_fail", "expect_failure", "expected_fail", or
>  > "expected_failure", 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