This patch adds the behaviour that when a unittest.failureException is
thrown in a TestCase's tearDown method, the test case is added to the
failures list (instead of the errors list, and only when the test case
body has passed successfully).

In some circumstances, tests may want to assert that something happens
at some point during the body of a test, and the best time to make these
checks can be in the tearDown method.

This is a modification I've made during development of my mocktest
library (https://github.com/gfxmonk/mocktest/tree), and I believe it is
beneficial to have as the default unittest behaviour.

updated patch: made the test method name unique (oops), and added the
specific test case where both test body and tearDown raise failure
exceptions. This patch supercedes the original (v0)

So I disagree with this idea. The point of a tearDown method is simply
to clean up, not to test for a failure. If the test failed because it
didn't complete a test and clean up after itself then the test should
fail explicitly, not have the tearDown do it for the test.

I concur with Brett.

I agree that this is not normally the point of tearDown methods.
However, allowing it reduces repetition when you want to verify that
some invariant is not violated by any test.

I also think that as far as the test writer is concerned, an assertion
error is a failed test - regardless of where in the code it came from.

Agreed with Brett and Raymond.
Besides, I'm not sure how getting a failure rather an error changes
anything in the big picture (for my non native English-speaking brain,
it certainly doesn't make a difference :-)).

In my mind, an error means something is wrong. A failure just means a
test case hasn't been implemented yet, or has regressed. For me it's
misleading to have an AssertionError reported as a failure. It's not as
if changing the reporting in this way could cause tests to succeed when
they should fail (or vice versa) - so it seems like there is no downside
to including this behaviour.

I concur with other developers. In strict unittesting, assertions of
correct behavior should only ever happen in the test not during set up
or tear down.

Thanks for the patch and the attempt, Tim!