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

[Herman]

I followed the rule because it was a very good advice. For example,
def test_plus_1Plus1_2(self):
If this test fails, you immediately know that it's testing the "plus"
method, with 1  and 1 as the arguments, and expect to return 2.
Sticking this rule also means your test cases are small enough, so you
clearly know what you are testing on. Most of the time, the method
name is what you first see when your test fails. Another alternative
is to put meaningful string in each of the assert, which is probably
not practical. You are right, only people who really follow the TDD
method know the good things about it. This naming rule served me very
well.

Tests method should have meaningful name, and the advice by the book
is a meaningful one. I said it's the TDD book because I forgot the
exact title. It's actually called Test Driven: TDD and Acceptance TDD
for Java Developers. I thought it should be popular enough that most
people learned TDD may have heard it also used this naming advice, but
look like i was wrong.

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