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

[Steve Holden]

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?
> 
Definitely not. I thin we are in danger of insisting on a foolish 
consistency. I'd far prefer readability (hence my preference for is_not 
over not_is). There's also the (possibly marginal) point that people 
used to Junit can actually understand Python unit tests right now. 
Surely there's something to be said for consistency across languages, 
especially when the idea was lifted from Java in the first place.

> 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.
> 
> 
>> 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.
> 
> 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
> 
And the way Thunderbird has wrapped your example makes it obvious that 
72 is a more satisfactory limit, though I agree transmissibility via 
email shouldn't necessarily be a factor.

> 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).
> 
I'm not quite sure how often it has to be pointed out that since 2.5 all 
unittest classes *are* new-style classes. Benjamin has, I believe, 
already mentioned twice that unittest.py contains

__metaclass__ = type

before any class declarations. While this has no effect on pre-2.2 
implementations, surely it means that we've been using new-style classes 
for some time now. Or am I missing some subtlety? 2.5.1 says:

 >>> isinstance(unittest.TestCase, type)
True

> Also, are there any expected benefits from making this change in 2.7?  
> What will the module do differently?
> 
> It seems like a risky change for zero-benefit.
> 
Better revert it, then :-)

But easier to just drop that sentence from the PEP.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/