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

Ben Finney bignose+hates-spam at benfinney.id.au
Tue Jul 15 12:17:23 CEST 2008


"Raymond Hettinger" <python at rcn.com> writes:

> > ``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 spell them as two words. The existing unittest framework also spells
them as two words, using camelCase.

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

I don't see the connection of this sentence to the existing discussion.

> 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

Yikes. Why are you using such huge indents? Break the line where
indents won't be so enormous.

class TestMisc(unittest.test_case):
   def lost_four_spaces_here_already(self):
       self.fail_if_almost_equal(
           'we know this is going to be long, so we indent before'
           'writing anything substantive',
           self.testedobject.tested_method(
               arg1, arg2 + arg3, arg4)

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

I'm very much in favour of having the namessay exactly what they're
testing. They need to be long because there are many of them doing
slightly-different things, so need careful disambiguation.

> 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).

Yes, this is something that deserves consideration.

-- 
 \            “Why was I with her? She reminds me of you. In fact, she |
  `\                reminds me more of you than you do!” —Groucho Marx |
_o__)                                                                  |
Ben Finney



More information about the Python-Dev mailing list