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. 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 - routines for comparing large lists and strings that produce useful output indicating exactly where the inputs differ. - assertLess etc. - assertSameElements (sort of like assert(set(x) == set(y)) --Guido On Thu, Apr 17, 2008 at 6:49 AM, Michael Foord <[EMAIL PROTECTED]> 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!): > > 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 > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
