[Python-Dev] Proposed unittest changes
Michael Foord
fuzzyman at voidspace.org.uk
Thu Apr 17 15:49:15 CEST 2008
Hello all,
I'm starting to put together a list of cleanups (with documentation
changes) for the unittest module. I thought someone had already done
this but the issue with the most comments I could find was 2578 which
doesn't go into much detail:
http://bugs.python.org/issue2578
The thing most people would like is test discovery - but that probably
requires some discussion before anything can be added to unittest.
What I would like to do is PEP-8'ify the method names (widening the API
rather than shrinking it!):
assert_true
assert_false
assert_equals
assert_not_equals
assert_raises
set_up
tear_down
failure_exception (? - class attribute)
TestSuite.add_test
(etc)
Documenting that these are to be preferred to 'assertEquals' and
'failUnlessEquals' (etc) and that the 'assert' statement should be used
instead of 'assert_'.
Adding the following new asserts:
assert_in (member, container, msg=None)
assert_not_in (member, container, msg=None)
assert_is (first, second, msg=None)
assert_not_is (first, second, msg=None)
assert_raises_with_message (exc_class, message, callable, *args,
**keywargs)
A decorator to turn a test function into a TestCase ("as_test_case" ?).
A simple 'RunTests' function that takes a collection of modules, test
suites or test cases and runs them with TextTestRunner - passing on
keyword arguments to the test runner. This makes running a test suite
easier - once you have collected all your test cases together you can
just pass them to this function so long as you are happy with the
default runner (possibly allowing an alternative runner class to be
provided as a keyword argument).
I would provide an implementation for discussion of course.
I would also like to make the error messages for "assert_equals" and
"assert_not_equals" more useful - showing the objects that compare
incorrectly even if an explicit message is passed in. Additionally, when
comparing lists and tuples that are the same length show the members
(and indices?) that were different.
I've copied Steve Purcell into this email, but his comments on issue
2578 indicate that he is happy for 'us' to make changes and he no longer
has a string sense of "ownership" of this module.
Michael Foord
More information about the Python-Dev
mailing list