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

Jesse Noller jnoller at gmail.com
Thu Apr 17 17:19:35 CEST 2008

On Thu, Apr 17, 2008 at 10:59 AM, Michael Foord <fuzzyman at voidspace.org.uk> 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 > <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

+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

More information about the Python-Dev mailing list