On Thu, Apr 17, 2008 at 10:59 AM, Michael Foord <[EMAIL PROTECTED]> wrote: > 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? > > * Decorator to make a function a TestCase > * Convenience RunTests functions taking modules, suites and TestCases > and running them > * Improved messages for assertEquals and assertNotEquals when an > > explicit message is passed in > * Improved message when comparing lists/tuples with assertEquals > * The additional asserts that I suggested (In/NotIn, RaisesWithMessage, > Is/NotIs) > > 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 > > <[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
+1 on your changes Michael - I really like the decorator idea. Let me know if you want help on adding the new stuff or updating the documentation. What about aiming this at 2.6 instead of 3.0? -jesse _______________________________________________ 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
