[TIP] Unittest Changes

holger krekel holger at merlinux.eu
Fri Jul 25 00:32:14 PDT 2008

Hi Jean-Paul, all, 

On Wed, Jul 23, 2008 at 08:20 -0400, Jean-Paul Calderone wrote:
> 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.

aren't debuggability/maintenance problems maybe also attributable 
to the deferred/asynchronous model exposed by twisted?  

> 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.

With py.test lots of projects and people use free assert
statements.  I am not aware that people attribute readability
or debuggability problems to it, rather the opposite. 

It definitely reduces the "number of names needed to get going"
because you just use "assert len(somelist) == 1" and so on without 
the need to think much.  But surely, you still need to think
about how to write sensible tests - recently i have been wading 
through test code that needed serious refactoring to become
more maintainable (and it doesn't use twisted :) 



collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 

More information about the testing-in-python mailing list