[Python-Dev] Proposed unittest changes

[Michael Foord]

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
>>  _______________________________________________
>>  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
>>
>>     
>
>
>
>