[TIP] Unittest Changes

[Jean-Paul Calderone]

On Tue, 22 Jul 2008 09:35:57 +0100, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>Pekka Laukkanen wrote:
> [snip]
>>
>> At least I don't see any reason why it would not. There's some extra
>> work in changing filtering of the traceback so that not only lines
>> originating inside 'unittest' but also inside 'asserts' are ignore.
>> That shouldn't be too hard, though.
>>
>>
>
>If you do try it - post the results back to the list.
>

This is something we experimented with in trial.  We're still recovering
from the fallout.  For unit tests, this feature seems only to lead to
confusingly written tests that are hard to debug and maintain.  There
seems to actually be a strong advantage to only being able to make test
assertions when the TestCase instance is nearby.  For examples of code
written in a style using free assertion functions, you can take a look at
<http://twistedmatrix.com/trac/browser/trunk/twisted/conch/test/test_ssh.py>.
The primary identifying feature of this code is that it's unclear what
the purpose of the free assertions are: it's hard to find out which test
they belong to, so it's hard to figure out what state has been set up for
them to make assertions about; it's also often hard to figure out where
failed assertions came from, since they may have been invoked beneath
application code which does its own exception handling, nothing prevents
that code from doing whatever it likes with the exception the assertion
functions raise.

We're still working hard to get rid of all code written in this style so
that we can delete these free function variations.

So as a unittest feature, I don't think this is a good one.  I don't know
about Robot or other uses.

Jean-Paul