[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:


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!):

    failure_exception (? - class attribute)


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, 

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