[Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Michael Foord]

Raymond Hettinger wrote:
>> ``set_up(…)``
>>  Replaces ``setUp(…)``
> . .
>> ``tear_down(…)``
>>  Replaces ``tearDown(…)``
>
> Am I the only one who finds this sort of excessive pep-8 underscoring 
> to be horrorific?
>
> Nobody I know spells setup and teardown as two words. I dread using 
> the module with these new names. Underscores are not fun to type. They 
> create a weird_mental_pause when reading them.
>
> It's not going to be easy to remember where they are used (ie. 
> isinstance is still isinstance but isset is now is_set). Go figure.

+1

setUp and tearDown should become setup and teardown.

>
>
>> fail_if_almost_equal
>
> Another thought is that test suite code is going to get seriously 
> crunched when the new, longer method names meet the 78/80 column pep 8 
> restrictions.

Well... "assert_not_equal"  is slightly shorter, "assert_notequal" 
slightly more so. Still one char longer than the original though.

>
> class TestMisc(unittest.test_case):
>    def lost_four_spaces_here_already(self):
>        self.fail_if_almost_equal('were already on the 34th column before'
>                                  'writing anything substantive',
>                                  self.testedobject.tested_method(arg1, 
> arg2 +
>                                                                  arg3, 
> arg4)
>        # Imagine typing and line wrapping dozens more tests like this
>
> Are there any ideas for some short, pithy, mnemonic names that are 
> self-explantory and not full of underscores; something that wouldn't 
> suck to type hundreds of times in a good test module?  IMO, the 
> current names are already too long.
>
>
>> * Explicit is better than implicit:
>
> Don't forgot the opposing forces:
>
> Beautiful is better than ugly.
> Readability counts.
>
> These are especially important for the unittest module.  When I'm 
> making tests, I have to type self.very_long_method_name so many times 
> it isn't funny.  It's easy to just stop writing tests when you get 
> tired of it.  Long api names with underscores are a disincentive (IMO).
>
>
>> Use new-style classes throughout
>
> This makes sense for 3.1 but of course we already get that 
> automatically for 3.0 ;-)
>
> For 2.7, it doesn't make as much sense.  Since 2.2 came out, there 
> have been many discussions on changing standard library code to use 
> new-style classes.  There was always some concern about subtle changes 
> in semantics and for the most part these requests were denied.  I 
> think this reason applies with even more force to the unittest 
> module.  Any risk that we subtlely break someone's test-suite is a 
> small disaster.  The 2.6 and 2.7 unittests need to be absolutely 
> stable if they are to serve as a transition tool (providing a baseline 
> the 3.0/3.1 is expected to match).
>
> Also, are there any expected benefits from making this change in 2.7?  
> What will the module do differently?

It would allow you to use properties in testcases. Not sure if there is 
a usecase for this though.

It looks like Benjamin Peterson is right, in Python 2.5 TestCase already 
appears to be a new style class:

Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import unittest
 >>> type(unittest.TestCase)
<type 'type'>
 >>>

>
> It seems like a risky change for zero-benefit.
>

Looks like that part of the PEP is unnecessary.

Michael

>
> Raymond
> _______________________________________________
> 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/fuzzyman%40voidspace.org.uk 
>


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/