[TIP] Unittest Changes

Michael Foord fuzzyman at voidspace.org.uk
Sun Jul 20 14:16:43 PDT 2008

Hello all,

As I'm sure many of you are aware there was recently a *very* long 
discussion on Python-Dev about possible changes to Python-Dev.

The original intention was to PEP-8'ify and slim down the duplication 
between 'fail*' and 'assert*' methods in the API. This caused a great 
deal of controversy, and Guido ruled that these parts of the proposed 
changes should not be acted on - but some new features could be added, 
following only the 'assert*' naming pattern for new test methods.

I'm also aware that many on this list aren't fond of unittest, 
preferring nose or py.test. Although I find the (manual) test collection 
part of unittest annoying - I find the API for actually writing tests 
straightforward. I've also found it not over difficult to extend when 
needed. I realise that this doesn't match other people's experiences and 
tastes and I would rather not debate this particular issue as part of 
this thread. :-)

Unless someone beats me to it I'm intending to work on some improvements 
to unittest after I have finished "IronPython in Action", which 
realistically will be a couple more months.

The biggest way I can think of improving unittest is to add automatic 
test discovery:

    unittests.discover_tests(path='.', pattern='test*.py', recurse=True)

This will simply search the path provided (defaulting to the current 
directory) matching test files based on the pattern.

With appropriate changes to unittest when run as __main__ so that you 
can do:

     python -m unittest [<directory> [<filter>]]

Along with this a 'run_tests' function that takes any number of modules, 
test cases and test suites and consolidates them into a single test 
suite and runs them (defaulting to use TextTestRunner).

Another change will be the improvement of failure message for 
assertEquals. When comparing long strings it will show a diff, when 
comparing containers it will show you the members that are different 
(lists, sets, dictionaries).

Other minor changes - have assertRaises return the exception instance so 
that you can assertions about it, possibly container membership 
assertion methods, nothing spectacular.

Any other good ideas about ways that unittest could change that don't 
either grow the API greatly or break backwards compatibility?

Michael Foord


More information about the testing-in-python mailing list