Можно ли разбить длинное название на несколько строк?

вы может также написать декоратор, который мутирует .__name__ для данного метода.

def test_name(name):
    def wrapper(f):
        f.__name__ = name
        return f
    return wrapper

тогда вы могли бы написать:

class ClientConnectionTest(unittest.TestCase):
    @test_name("test_that_client_event_listener_"
    "receives_connection_refused_error_without_server")
    def test_client_offline_behavior(self):
        self.given_server_is_offline()
        self.given_client_connection()
        self.when_client_connection_starts()
        self.then_client_receives_connection_refused_error()

полагаясь на то, что Python конкатенирует исходные соседние строковые литералы.

в ответ на этот вопрос:Как отключить ошибку pep8 в конкретном файле? используйте # nopep8 или # noqa трейлинг комментарий, чтобы отключить PEP-8 для длинной линии. Важно знать, когда нарушать правила. Конечно, Дзен питона сказал бы вам, что " особые случаи не являются достаточно особенными, чтобы нарушить правила."

мы можем применять оформителя к классу вместо метода, так как unittest получить имя метода от dir(class).

дизайнер decorate_method будет проходить через методы класса и переименовать имя метода на основе func_mapping словарь.

подумал об этом, увидев ответ декоратора от @Sean Vieira, +1 от меня

import unittest, inspect

# dictionary map short to long function names
func_mapping = {}
func_mapping['test_client'] = ("test_that_client_event_listener_receives_"
                               "connection_refused_error_without_server")     
# continue added more funtion name mapping to the dict

def decorate_method(func_map, prefix='test_'):
    def decorate_class(cls):
        for (name, m) in inspect.getmembers(cls, inspect.ismethod):
            if name in func_map and name.startswith(prefix):
                setattr(cls, func_map.get(name), m) # set func name with new name from mapping dict
                delattr(cls, name) # delete the original short name class attribute
        return cls
    return decorate_class

@decorate_method(func_mapping)
class ClientConnectionTest(unittest.TestCase):     
    def test_client(self):
        # dummy print for testing
        print('i am test_client')
        # self.given_server_is_offline()
        # self.given_client_connection()
        # self.when_client_connection_starts()
        # self.then_client_receives_connection_refused_error()

тестовый запуск с unittest как показано ниже, полное длинное описательное имя функции, думает, что это может работать для вашего случая хотя это может звучать не так элегантно и читаемый из реализации

>>> unittest.main(verbosity=2)
test_that_client_event_listener_receives_connection_refused_error_without_server (__main__.ClientConnectionTest) ... i am client_test
ok

своего рода контекстно-специфический подход к проблеме. Тестовый случай, который вы представили, на самом деле очень похож на формат естественного языка описания необходимых шагов для выполнения тестового случая.

смотрите, если с помощью behave структура стиля разработки драйверов поведения здесь было бы больше смысла. Ваша "функция" может выглядеть так (см. Как given,when,then задумайтесь, что у вас было):

Feature: Connect error testing

  Scenario: Client event listener receives connection refused error without server
     Given server is offline
      when client connect starts
      then client receives connection refused error

там тоже уместно pyspecs пакета, пример использования из недавнего ответа на связанную тему:

• написать описательные модульные тесты

более короткое решение имени функции имеет много достоинств. Подумайте о том, что такое действительно требуется в вашем фактическом имени функции и то, что уже поставляется.

test_that_client_event_listener_receives_connection_refused_error_without_server(self):

конечно, вы уже знаете, что это испытание, когда вы запустите его? Вам действительно нужно использовать подчеркивания? действительно ли такие слова, как "это", необходимы для понимания имени? будет ли случай с верблюдом таким же читаемым? как насчет первого примера ниже, как переписывание выше (количество символов = 79): Принятие соглашения об использовании сокращений для небольшого набора общих слов еще более эффективно, например Connection = Conn, Error = Err. При использовании сокращений вы должны помнить о контексте и использовать их только тогда, когда нет возможности путаницы - второй пример ниже. Если вы согласны с тем, что нет фактической необходимости упоминать клиента в качестве испытуемого в имени метода, поскольку эта информация находится в имени класса, то третий пример может быть подходящим. (54) письмена.

ClientEventListenerReceivesConnectionrefusederrorwithoutserver (self):

ClientEventListenerReceivesConnRefusederrwithoutserver (self):

EventListenerReceiveConnRefusedErrwithoutserver (self):

Я бы также согласился с предложением от B Rad C " использовать описательное имя в качестве msg kwarg arg в себе.assert " вы должны быть заинтересованы только в том, чтобы увидеть вывод из неудачных тестов при запуске testsuite. Проверка того, что вы наличие всех необходимых тестов не должно зависеть от того, что имена методов настолько детализированы.

P. S. Я бы, наверное, также удалить 'WithoutServer' за ненадобностью, а также. Разве обработчик событий клиента не должен получать событие в случае, если сервер не может связаться по какой-либо причине? (хотя tbh я думаю , что было бы лучше, если бы клиент не мог подключиться к серверу, он получает какое-то "соединение недоступно", отказ от подключения предполагает, что сервер может быть найдено, но отказывается от самого соединения.)

потребность в такого рода именах может намекать на другие запахи.

class ClientConnectionTest(unittest.TestCase):
   def test_that_client_event_listener_receives_connection_refused_error_without_server(self):
       ...

ClientConnectionTest звучит довольно широко (и совсем не похоже на тестируемый блок), и, вероятно, большой класс с большим количеством тестов внутри, которые могут быть перефокусированы. Вот так:

class ClientEventListenerTest(unittest.TestCase):
  def receives_connection_refused_without_server(self):
      ...

"тест" не полезен в названии, потому что это подразумевается.

со всем кодом, который вы мне дали, мой последний совет: рефакторинг вашего тестового кода, а затем вернуться к вашей проблеме (если она все еще там).