[Python-Dev] Proposed unittest changes

[Jesse Noller]

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