I think that it would be good for expectedFailure to take a message argument like skip does.  My thought is that it would be printed both when it is triggered (the test fails as expected) so that one case from the verbose output why the test is expected to fail, and when the test passes unexpectedly.  My specific use case is OS bugs, where we could mark a test as an expected failure instead of a skip, and then we would see the unexpected pass when the OS fixes the bug, but in the meantime the verbose output would show the 'skip' reason.

Hmm.  I suppose this means I want expectedFailureIf, too...

Too late I'm afraid as expectedFailure not expectedFailure() is the decorator.

Well, expectedFailure could dispatch on the type of the argument, with different behaviour for strings and anything else (presumed to be a function / method). That would be inconsistent with the api for skipping though. (I'm not wild on the message argument to the skip decorators - I keep forgetting it.)

It would be nice if expectedFailure took a bug number and printed a url to the tracker.

Well, it would be nice for the Python test suite, maybe not so useful for external users of the api. Something for regrtest rather than unittest I think.

Maybe we could add an expected_issue(id) decorator to test.support.

I've got a patch for this, but I'm a bit worried about the impact on the documented API. I've tried to do the best I could to minimize it through use of keyword-arguments but I'm a bit unsure about the change (and the docs too!)

I hope this is useful to someone!

Thanks, Adam.  I'm afraid it may be a while before Michael (or anyone else) gets a chance to review it and think about the issue some more.

Such change would break a lot of existing interfaces.

* addUnexpectedSuccess() has a single parameter. The change will add the second parameter and will break subclasses of TestResult.
* addExpectedFailure() has two parameter. The change will add the third parameter and will break subclasses of TestResult.
* unexpectedSuccesses is a list of tests. The change will make it a list of 2-tuples and will break users of TestResult.
* expectedFailures is a list of 2-tuples. The change will make it a list of 3-tuples and will break users of TestResult.

It is too destructive change. I think we can live without a message argument for expectedFailure().