Ну, повторная реализация build_help_message
в вашем тесте определенно не лучше. То, что вы могли бы сделать (и что здесь могут порекомендовать пуристы unittest), это переписать help_handler
, чтобы вы могли внедрить зависимость build_message
, то есть:
def help_handler(payload, build_help_message=build_help_message):
team_id = payload['team_id']
user_id = payload['user_id']
message = build_help_message(team_id, user_id)
Client(team_id).send_message(user_id, **message)
, а затем и насмешку build_message
- но пуристы юнит-теста также хотели бы, чтобы вы сделали то же самое с Client
(вместо использования Mock
) в любом случае.
Теперь, хотя внедрение зависимостей является очень мощным решением некоторых проблем и того, о чем должен знать каждый разработчик, применение его повсеместно во имя «тестируемости» чаще всего является пустой тратой времени по сравнению с выгодой - по крайней мере когда язык достаточно динамичен, чтобы поддерживать разбор обезьян, конечно, - и не обязательно помогает читаемости.
Для вашего примера, насколько мне известно, без контекста (всегда сложно принять обоснованное решение, не зная проекта), я действительно не стал бы беспокоиться о том, чтобы делать что-то большее - кроме, конечно, юнит-тестирования build_help_message
тоже, но я предполагаю, что это уже так; -)