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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4