Касательно чтения инструкций GoogleMock — дать однозначный ответ мне кажется затруднительно — вероятно, во многом это зависит от психологических особенностей восприятия того или иного кода.
Говоря же в статье об использовании в тесте единственного assert, я хотел отметить, что не стоит в одном тесте подвергать проверке несколько несвязанных друг с другом задач. В указанном вами примере, мне кажется, может быть оправдано использование приведенного вами подхода – поскольку, по сути, тестируется один результат, возвращаемый функцией.
Однако, возникший вопрос приводит к появлению некоторых мыслей. Так, например, если функция возвращает два значения, то, возможно, их следует отнести к одной общей сущности. При чтении кода — это позволит подчеркнуть связанность этих данных, а, в свою очередь, при написании тестов это позволит нам обойтись одним assert.
Если же эти данные никак не связаны друг с другом, то, возможно, нам следует повнимательней приглядеться к этой функции — а не возложена ли на нее слишком большая ответственность? Не пытается ли она решить внутри себя несколько несвязанных друг с другом задач? Не нужно ли запланировать ее рефакторинг?
О чем нам говорит возникновение таких мыслей? А говорит это о том, что возникающие вопросы о том, как написать тест для того или иного модуля — это хорошо. Подвергание проекта тестированию способствует «выпрямлению» кода — переосмыслению его архитектуры с целью выделения, в частности, прозрачных контрактов.
В любом случае, приведенные в статье рекомендации не являются панацеей от всех проблем. В реальном проекте следует выбирать тот вариант тестирования, который для конкретной команды является более понятным и легким с точки зрения разработки и дальнейшей поддержки.
Также спасибо вам за аргументированный комментарий.
Говоря же в статье об использовании в тесте единственного assert, я хотел отметить, что не стоит в одном тесте подвергать проверке несколько несвязанных друг с другом задач. В указанном вами примере, мне кажется, может быть оправдано использование приведенного вами подхода – поскольку, по сути, тестируется один результат, возвращаемый функцией.
Однако, возникший вопрос приводит к появлению некоторых мыслей. Так, например, если функция возвращает два значения, то, возможно, их следует отнести к одной общей сущности. При чтении кода — это позволит подчеркнуть связанность этих данных, а, в свою очередь, при написании тестов это позволит нам обойтись одним assert.
Если же эти данные никак не связаны друг с другом, то, возможно, нам следует повнимательней приглядеться к этой функции — а не возложена ли на нее слишком большая ответственность? Не пытается ли она решить внутри себя несколько несвязанных друг с другом задач? Не нужно ли запланировать ее рефакторинг?
О чем нам говорит возникновение таких мыслей? А говорит это о том, что возникающие вопросы о том, как написать тест для того или иного модуля — это хорошо. Подвергание проекта тестированию способствует «выпрямлению» кода — переосмыслению его архитектуры с целью выделения, в частности, прозрачных контрактов.
В любом случае, приведенные в статье рекомендации не являются панацеей от всех проблем. В реальном проекте следует выбирать тот вариант тестирования, который для конкретной команды является более понятным и легким с точки зрения разработки и дальнейшей поддержки.
Также спасибо вам за аргументированный комментарий.