[TIP] Unittest Changes
fuzzyman at voidspace.org.uk
Sun Jul 20 14:16:43 PDT 2008
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
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
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?
More information about the testing-in-python