[Python-Dev] Proposed unittest changes (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Thu Apr 17 16:59:01 CEST 2008

Guido van Rossum wrote:

I'm worried that a mass renaming would do anything but inconvenience users during the already stressful 2->3 transition.

I'm more in favor of the original proposal of reducing the redundancy post-3.0.

So nix the PEP-8'ifying until after 3.0.

So new methods should follow the current naming scheme (assertIn, assertNotIn etc).

If you're looking for useful features, Google has a set of extensions to unittest.py that I find useful:

- module-level setUp and tearDown So when a suite is made from a module the setUp should be called before the first test and tearDown after the last. I can look at that.

- routines for comparing large lists and strings that produce useful output indicating exactly where the inputs differ.

- assertLess etc. By etc I assume you mean:

assertLessThan
assertGreaterThan
assertLessThanOrEquals
assertGreaterThanOrEquals

Would not variants be useful as well - it seems not as the not of one is always another... (I think 'assertLessThan' reads better than 'assertLess' but will do what I'm told...)

- assertSameElements (sort of like assert(set(x) == set(y))

Sounds good.

Did you look at the other proposals?

I think that there is still work I can do on the docs even before any grand renaming...

Michael Foord

--Guido

On Thu, Apr 17, 2008 at 6:49 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

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!): asserttrue assertfalse assertequals assertnotequals assertraises setup teardown failureexception (? - class attribute) TestSuite.addtest (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: assertin (member, container, msg=None) assertnotin (member, container, msg=None) assertis (first, second, msg=None) assertnotis (first, second, msg=None) assertraiseswithmessage (excclass, message, callable, *args, **keywargs) A decorator to turn a test function into a TestCase ("astestcase" ?). 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 "assertequals" and "assertnotequals" 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

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

More information about the Python-Dev mailing list