[TIP] Unittest Changes

[Pekka Laukkanen]

2008/7/29 John Arbash Meinel <john at arbash-meinel.com>:
> Pekka Laukkanen wrote:
> | 2008/7/22 Andrew Bennetts <andrew-tip at puzzling.org>:
> |> Also, IIRC assertion methods in unittest.TestCase raise
> self.failureException
> |> rather than a hard-coded exception.  This is a bit of a minor
> feature, but it
> |> wouldn't be possible if the assertions weren't methods.
> |
> | Even though this is a minor feature, I've actually used it at least
> | once when I implemented something on top of unittest. Having global
> | FAILURE_EXCEPTION in asserts module would make changing the exception
> | nearly as easy (import asserts; asserts.FAILURE_EXCEPTION =
> | MyCustomExceptio), but would have more side-effects. This probably
> | wouldn't be too big problem especially when the old mechanism would
> | still be there.
>
> At least, until 2 people decide to do it at the same time, and then at
> least one of them breaks.
>
> The really nice thing about the context of a class is that you are
> isolated from the other classes. Then again, sometimes people don't want
> that isolation, depending on what is layered on top.

Yes, that's true (and exactly what I meant with 'side-effects'). I
don't believe it would be a problem in practice because a) there
aren't that many use cases for it (what I did could've been done
otherwise too), b) I don't know any framework using it in practice
(couldn't find anything with Google either), and c) old approach would
still be there.

It might anyway be better to name the module global variable
_FAILURE_EXCEPTION to make it more clear that changing it is not
always safe.

Cheers,
      .peke