How to break long method name into more than one line?

[Herman]

I am trying to stick to the rule described in the TDD book that, each
test method name consists of the method name to be tested, inputs and
the expected outputs. It takes up a lot of space and my company has a
rule of limiting 79 characters (or 80) per line. I found that
def abcdeef\
dddaaa(self):
pass

does not work, but
def \
abcsajfoijfiawifoiwejfoi(self):
pass

works. Is this the only way to do it?

 

[Roy Smith]

I am trying to stick to the rule described in the TDD book that, each
test method name consists of the method name to be tested, inputs and
the expected outputs. It takes up a lot of space and my company has a
rule of limiting 79 characters (or 80) per line. I found that
def abcdeef\
dddaaa(self):
pass

does not work, but
def \
abcsajfoijfiawifoiwejfoi(self):
pass

works. Is this the only way to do it?

Arrrrrrrrhhhggggg. If you can't fit a test method name into 79
characters, you're doing somthing wrong. Just for fun, I found all the
test methods in the project I'm working on and sorted them by length.
Here's the top of the list:

$ find . -name 'test*py' | xargs grep -h 'def *test' | sort | uniq |
awk '{print length($0), $0}' | sort -nr
55 def test_update_name_changes_dasherized_name(self):
51 def test_get_followers_with_no_followers(self):
50 def test_update_station_song_adds_false(self):
50 def test_anonymous_get_user_collections(self):
49 def test_wrong_user_update_should_fail(self):
49 def test_login_with_email_and_password(self):
47 def test_unknown_station_returns_404(self):
47 def test_login_failure_with_facebook(self):
47 def test_get_follows_with_no_follows(self):
46 def test_station_by_dasherized_name(self):
46 def test_nonexistent_recent_station(self):
46 def test_new_user_with_display_name(self):
46 def test_auto_connect_with_facebook(self):
46 def test_anonymous_created_stations(self):
45 def test_no_php_fatal_error_in_log(self):
45 def test_get_only_songza_followers(self):
45 def test_anonymous_vote_transition(self):
44 def test_non_ascii_global_station(self):
44 def test_global_station_not_found(self):
44 def test_gallery_create_duplicate(self):
44 def test_anonymous_listen_history(self):

and so on down to the wonderfully terse:

21 def test_x(self):

which I'm assuming actually makes sense in the context of the TestCase
class it belongs to. At least I hope it does

The examples above are a reasonable upper limit on the verbosity you
should be shooting for, IMHO.

 

[Steven D'Aprano]

I am trying to stick to the rule described in the TDD book that, each
test method name consists of the method name to be tested, inputs and
the expected outputs.

*The* TDD book? There's only one? Surely not.

That rule sounds utterly impractical. I can't think of anything to
recommend it. Like any other function, method or class, tests should have
meaningful names, but reading the name alone should not necessarily tell
you *everything* about the function.

We have "len", not "len_sequence_or_mapping_int", and similarly it is
perfectly reasonable to have "test_len_empty" rather than
"test_len_emptylist_emptystr_emptyunicode_emptydict_emptyset_emptytuple_zero".

I expect that naming rule was invented by either people who have heard of
test driven development, but never actually done it, or by people so
anally-retentive that if they make seven short car trips over an hour,
they check the tyre pressure, oil and water seven times because "the
manual says to check before *every* trip".

No offence.

My advice is to moderate the naming convention of your tests with a good
dose of common sense and aim for names which are readable rather than
names that contain everything including the kitchen sink. Imagine you are
in a technical meeting with some of your fellow programmers, and need to
ask for help with a failing test. Imagine saying the name of the test
aloud in a sentence. Does it add clarity to the discussion, or obfuscate
it?

People's short term memory can only hold so much (allegedly "seven plus
or minus two"), and if the name itself hits that limit, you leave nothing
left for the rest of the sentence.

http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

Names should be practically, rather than conforming to some naming rule
that hurts readability and obfuscates the tests.

It takes up a lot of space and my company has a
rule of limiting 79 characters (or 80) per line. I found that def
abcdeef\
dddaaa(self):
pass

does not work, but
def \
abcsajfoijfiawifoiwejfoi(self):
pass

works. Is this the only way to do it?

Yes. You can't split tokens over multiple lines, or put any whitespace
between them.

 

[Roy Smith]

You can't split tokens over multiple lines, or put any whitespace
between them.

Well, if you truly wanted to be perverse, you could write some kind of
decorator:

@make_long_named_test_method('some',
'very',
'long',
'list',
'of',
'token',
'fragments')
def x(self):
blah, blah, blah

which creates a "test_some_very_long_list_of_token_fragments" method.
But it would be a lot easier to just use sane method names.

 

[Dennis Lee Bieber]

off topic observation...

I expect that naming rule was invented by either people who have heard of
test driven development, but never actually done it, or by people so
anally-retentive that if they make seven short car trips over an hour,
they check the tyre pressure, oil and water seven times because "the
manual says to check before *every* trip".

By which time they find they have to add air, oil, and water as: the
pressure gauge usage lets out some air each time; they've wiped a few
drops of oil onto a rag each time; and the radiator was still
hot&pressurized such that they got an "overfull" result.

 

[Chris Angelico]

       By which time they find they have to add air, oil, and water as: the
pressure gauge usage lets out some air each time; they've wiped a few
drops of oil onto a rag each time; and the radiator was still
hot&pressurized such that they got an "overfull" result.

In defense of such rules: There's a period in every new programmer's
life when it helps to learn a whole lot of principles; and if he's
working on some collaborative project, rules are the easiest way to
demand such behavior. Later on, you learn how and when it's safe to
break the rules (and/or how to deal with rule conflicts), but the
rules still have value. Just never treat them as laws of physics (in
Soviet Physics, rules break you!).

ChrisA

 

[Jean-Michel Pichavant]

Just never treat them as laws of physics (in
Soviet Physics, rules break you!).

ChrisA

hum ...
I wonder how this political message is relevant to the OP problem.

JM

 

[Chris Angelico]

hum ...
I wonder how this political message is relevant to the OP problem.

Ehh, it's a reference to the "in Soviet Russia" theme of one-liners.
You don't break the laws of physics, they break you. My point is that
rules about function names etc are *not* inviolate, and should be
treated accordingly.

ChrisA