Эта статья является переводом материала «When to Mock».

Использование моков в модульном тестировании является спорной темой. Автор оригинала заметил, что на протяжении всей своей карьеры в программировании он сначала перешел от моков почти над каждой зависимостью к политике «без моков», а затем к «только моки для внешних зависимостей».

Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.

Что такое mock (мок, от англ. «пародия», «имитация»)?

Прежде чем перейти к теме того, когда использовать моки, давайте обсудим, что такое мок. Люди часто используют термины тестовый двойник (test double) и мок (mock) как синонимы, но технически это не так:

• Тестовый двойник - это всеобъемлющий термин, который описывает все виды фальшивых (fake) зависимостей, непригодных к использованию в конечном продукте (non-production-ready), в тестах. Такая зависимость выглядит и ведет себя как ее аналог, предназначенный для production, но на самом деле является упрощенной версией, которая снижает сложность и облегчает тестирование. Этот термин был введен Джерардом Месаросом в его книге «xUnit Test Patterns: Refactoring Test Code». Само название происходит от понятия дублера в кино.

• Мок – это лишь один из видов таких зависимостей.

Согласно Жерару Месарошу, существует 5 видов тестовых двойников:

• Пустышка (dummy)

• Стаб (stub)

• Шпион (spy)

• Мок (mock)

• Фейк (fake)

Такое разнообразие может показаться пугающим, но на самом деле все они могут быть сгруппированы всего в два типа: моки и стабы.

Разница между этими двумя типами сводится к следующему:

• Моки помогают имитировать и изучать исходящие (outcoming) взаимодействия. То есть вызовы, совершаемые тестируемой системой (SUT) к ее зависимостям для изменения их состояния.

• Стабы помогают имитировать входящие (incoming) взаимодействия. То есть вызовы, совершаемые SUT к ее зависимостям для получения входных данных.

Например, отправка электронной почты является исходящим (outcoming) взаимодействием: это взаимодействие приводит к побочному эффекту на SMTP-сервере. Тестовый двойник, имитирующий такое взаимодействие, - это мок.

Извлечение данных из БД является входящим (incoming) взаимодействием — оно не приводит к побочному эффекту. Соответствующий тестовый двойник является стабом.

Все остальные различия между пятью типами тестовых двойников являются незначительными деталями реализации:

• Spies (шпионы) выполняют ту же роль, что и моки. Отличие в том, что spies пишутся вручную, а моки создаются с помощью готовых инструментов. Иногда spies называют рукописными моками.

С другой стороны, разница между стабами, dummy (пустышками) и фейками заключается в том, насколько они умны:

• Dummy - это простое, жестко закодированное значение, такое как null значение или выдуманная строка. Он используется для удовлетворения сигнатуры метода SUT и не участвует в получении конечного результата.

• Стаб посложнее. Это полноценная зависимость, которую вы настраиваете для возврата разных значений для разных сценариев.

• Фейк - это то же самое, что и стаб для большинства целей. Разница заключается в причинах его создания: фейк обычно используется для замены еще не существующей зависимости.

Обратите внимание на разницу между моками и стабами (помимо исходящих и входящих взаимодействий). Моки помогают эмулировать и изучать взаимодействия между SUT и его зависимостями, в то время как стабы помогают только эмулировать эти взаимодействия. Это важное различие.

Мок-как-инструмент vs. мок-как-тестовый-двойник

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

Но у термина мок есть и другое значение. Вы также можете ссылаться на классы из библиотек (для создания моков) как на моки. Эти классы помогают вам создавать настоящие моки, но сами по себе они не являются моками как таковыми:

[Fact]
public void Sending_a_greetings_email()
{
    // Using a mock-the-tool to create a mock-the-test-double
    var mock = new Mock<IEmailGateway>();
    var sut = new Controller(mock.Object);

    sut.GreetUser("user@email.com");

    // Examining the call from the SUT to the test double
    mock.Verify(
        x => x.SendGreetingsEmail("user@email.com"),
        Times.Once);
}

В этом тесте используется класс Mock из библиотеки Moq. Этот класс представляет собой инструмент, который позволяет вам создавать тестовый двойник - мок. Другими словами, класс Mock (или Mock<IEmailGateway>) является мок-как-инструмент, в то время как экземпляр этого класса является мок-как-тестовый-двойник.

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

Вот еще один пример теста, в котором используется класс Mock. Экземпляр этого класса - стаб, а не мок:

[Fact]
public void Creating_a_report()
{
    // Using a mock-the-tool to create a stub
    var stub = new Mock<IDatabase>();
    // Setting up a canned answer
    stub.Setup(x => x.GetNumberOfUsers()).Returns(10);
    var sut = new Controller(stub.Object);

    Report report = sut.CreateReport();

    Assert.Equal(10, report.NumberOfUsers);
}

Этот тестовый двойник имитирует входящее взаимодействие – вызов, который предоставляет SUT входные данные. С другой стороны, в предыдущем примере вызов SendGreetingsEmail() является исходящим взаимодействием. Его единственная цель - вызвать побочный эффект - отправить электронное письмо.

Не проверяйте взаимодействия со стабами

Как уже упоминал выше, моки помогают эмулировать и изучать исходящие взаимодействия между SUT и его зависимостями, в то время как стабы помогают только эмулировать входящие взаимодействия, а не изучать их.

Из этого следует, что вы никогда не должны проверять взаимодействие со стабами. Вызов от SUT к стабу не является частью конечного результата, который выдает SUT. Такой вызов - это всего лишь средство для получения конечного результата; это деталь реализации. Проверка взаимодействий со стабами является распространенным анти-паттерном, который приводит к хрупким тестам.

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

В приведенных выше примерах проверка

mock.Verify(x => x.SendGreetingsEmail("user@email.com"))

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

В то же время вызов GetNumberOfUsers() вообще не является результатом. Это внутренняя деталь реализации, касающаяся того, как SUT собирает данные, необходимые для создания отчета. Следовательно, проверка этого вызова приведет к уязвимости теста. Неважно, как SUT генерирует конечный результат, если этот результат правильный.

Вот пример такого хрупкого теста:

[Fact]
public void Creating_a_report()
{
    var stub = new Mock<IDatabase>();
    stub.Setup(x => x.GetNumberOfUsers()).Returns(10);
    var sut = new Controller(stub.Object);

    Report report = sut.CreateReport();

    Assert.Equal(10, report.NumberOfUsers);
    // Asserting an interaction with a stub
    stub.Verify(
        x => x.GetNumberOfUsers(),
        Times.Once);

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

Моки - это более сложная тема: не все их использования приводят к уязвимости теста, но многие из них делают это. Вы скоро поймете почему.

Совместное использование моков и стабов

Иногда нужно создать тестовый двойник, который проявляет свойства как мока, так и стаба:

[Fact]
public void Purchase_fails_when_not_enough_inventory()
{
    var storeMock = new Mock<IStore>();
    // Setting up a canned answer
    storeMock
        .Setup(x => x.HasEnoughInventory(Product.Shampoo, 5))
        .Returns(false);
    var sut = new Customer();

    bool success = sut.Purchase(storeMock.Object, Product.Shampoo, 5);

    Assert.False(success);
    // Examining a call from the SUT to the mock
    storeMock.Verify(
        x => x.RemoveInventory(Product.Shampoo, 5),
        Times.Never);
}

Этот тест использует storeMock для двух целей: он возвращает шаблонный ответ и проверяет вызов метода, сделанный SUT.

Однако обратите внимание, что это два разных метода: тест устанавливает ответ от HasEnoughInventory(), но затем проверяет вызов RemoveInventory(). Таким образом, здесь не нарушается правило не проверять взаимодействия со стабами.

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

Mocks vs. stubs и commands vs. queries

Понятие моков и стабов связано с принципом command-query separation (CQS). Принцип CQS гласит, что каждый метод должен быть либо командой, либо запросом, но не обоими:

• Команды - это методы, которые вызывают побочные эффекты и не возвращают никакого значения. Примеры побочных эффектов включают изменение состояния объекта, изменение файла в файловой системе и т. д.

• Запросы противоположны этому - они не имеют побочных эффектов и возвращают значение.

Другими словами, задавая вопрос, вы не должны менять ответ. Код, который поддерживает такое четкое разделение, становится легче для чтения. Тестовые двойники, заменяющие команды, становятся моками. Аналогично, тестовые двойники, заменяющие запросы, являются стабами:

Посмотрите еще раз на два теста из предыдущих примеров:

var mock = new Mock<IEmailGateway>();
mock.Verify(x => x.SendGreetingsEmail("user@email.com"));

var stub = new Mock<IDatabase>();
stub.Setup(x => x.GetNumberOfUsers()).Returns(10);

SendGreetingsEmail() - это команда, побочным эффектом которой является отправка электронного письма. Тестовый двойник, который заменяет эту команду, является моком.

С другой стороны, GetNumberOfUsers() - это запрос, который возвращает значение и не изменяет состояние базы данных. Соответствующий тестовый двойник - стаб.

Когда мокать?

Разобравшись со всеми этими определениями, давайте поговорим о том, когда вам следует использовать моки.

Очевидно, что вы не хотите мокать саму тестируемую систему (SUT), поэтому вопрос «Когда мокать?» сводится к следующему: «Какие типы зависимостей вы должны заменять на моки, а какие использовать в тестах?»

Вот все типы зависимостей модульного тестирования, которые автор оригинала перечислил в своей предыдущей статье:

• Совместная зависимость (shared dependency) - это зависимость, которая является общей между тестами и с помощью нее тесты могут влиять на результаты друг друга.

• Приватная зависимость (private dependency) - это любая зависимость, которая не является совместной.

Совместная зависимость соответствует изменяемой внепроцессорной зависимости (mutable out-of-process dependency) в подавляющем большинстве случаев, поэтому автор оригинала использует здесь эти два понятия как синонимы. (Ознакомьтесь с предыдущим постом Владимира Хорикова, чтобы узнать больше: Unit Testing Dependencies: The Complete Guide.)

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

• Лондонская школа (также известная как школа mockist) выступает за замену всех изменяемых зависимостей на моки.

• Классическая школа (также известная как школа Детройта) выступает за замену только общих (изменяемых внепроцессорных) зависимостей.

Обе школы ошибаются в своем отношении к мокам, хотя классическая школа меньше, чем лондонская.

Моки и неизменяемые внепроцессорные зависимости.

А как насчет иммутабельных внепроцессорных (immutable out-of-process) зависимостей? Разве их не стоит мокать, по крайней мере, по мнению одной из школ? Неизменяемые внепроцессорные зависимости (например, служба API только для чтения) следует заменить тестовым двойником, но этот тестовый двойник будет стабом, а не моком.

Это опять же из-за различий между моками и стабами:

· Моки предназначены для исходящих взаимодействий (команд) - взаимодействий, которые оставляют побочный эффект в зависимости.

· Стабы предназначены для входящих взаимодействий (запросов) - взаимодействий, которые не оставляют побочных эффектов в зависимости.

Взаимодействия с иммутабельными внепроцессорными зависимостями по определению являются входящими и, следовательно, не должны проверяться в тестах, а только заменяться шаблонными ответами (обе школы с этим согласны).

Сначала Владимир Хориков опишет, почему лондонская школа ошибочна, а затем - почему классический подход тоже неверен.

Не мокайте все изменяемые зависимости

Не стоит мокать все изменяемые зависимости. Чтобы понять, почему, нам нужно рассмотреть два типа коммуникаций в типичном приложении: внутрисистемный и межсистемный.

• Внутрисистемные (Intra-system) коммуникации - это коммуникации между классами внутри вашего приложения.

• Межсистемные (Inter-system) коммуникации - это когда ваше приложение взаимодействует с другими приложениями.

Между ними существует огромная разница: внутрисистемные коммуникации являются деталями реализации; межсистемные коммуникации - нет.

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

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

Это свойство межсистемных коммуникаций проистекает из того, как отдельные приложения развиваются вместе. Один из основных принципов такой эволюции – обеспечение обратной совместимости. Независимо от рефакторинга, который вы выполняете внутри своего приложения, паттерн взаимодействия, который оно использует для взаимодействия с внешними приложениями, должен всегда оставаться на месте, чтобы внешние приложения могли его понять. Например, сообщения, отправляемые вашим приложением по шине, должны сохранять свою структуру и так далее.

Использование моков закрепляет контракт взаимодействия между тестируемой системой и зависимостью. Это именно то, что вам нужно при проверке связи между вашей системой и внешними приложениями. И наоборот, использование моков для проверки связи между классами внутри вашей системы связывает ваши тесты с деталями реализации, делая их хрупкими. Внутрисистемные связи соответствуют изменяемым внутрипроцессорным зависимостям:

Итак, лондонская школа ошибается, потому что она поощряет использование моков для всех изменяемых зависимостей и не проводит различия между внутрисистемными (внутрипроцессорными) и межсистемными (внепроцессорными) коммуникациями.

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

Не мокайте все внепроцессорные зависимости

Классическая школа лучше справляется с этим вопросом, потому что она выступает за замену только внепроцессорных зависимостей, таких как служба SMTP, шина сообщений и т. д. Но классическая школа также не идеальна по отношению к межсистемным коммуникациям. Эта школа также поощряет чрезмерное использование моков, хотя и не так сильно, как лондонская школа.

Не все внепроцессорные зависимости следует мокать. Если внепроцессорная зависимость доступна только через ваше приложение, то связь с такой зависимостью не является частью наблюдаемого поведения вашей системы. Внепроцессорная зависимость, которая не может наблюдаться извне, по сути, действует как часть вашего приложения. Связи с такой зависимостью становятся деталями реализации: они не должны оставаться неизменными после рефакторинга и, следовательно, не должны проверяться с помощью моков.

Помните, что требование всегда сохранять схему взаимодействия между вашим приложением и внешними системами проистекает из необходимости поддерживать обратную совместимость. Вы должны поддерживать способ взаимодействия вашего приложения с внешними системами. Это потому, что вы не можете изменять эти внешние системы одновременно с вашим приложением; они могут следовать другому циклу развертывания, или вы можете просто не контролировать их.

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

Хорошим примером здесь является БД приложения: БД, которая используется только вашим приложением. Ни одна внешняя система не имеет доступа к этой БД. Таким образом, вы можете изменить схему взаимодействия между вашей системой и БД приложения любым удобным вам способом, если это не ломает существующую функциональность. Поскольку эта БД полностью скрыта от глаз клиентов, вы даже можете заменить ее совершенно другим механизмом хранения, и никто этого не заметит.

Использование моков для внепроцессорных зависимостей, которые вы полностью контролируете, также приводит к хрупким тестам. Вы не хотите, чтобы ваши тесты становились красными каждый раз, когда вы разбиваете таблицу в БД или изменяете тип одного из параметров в хранимой процедуре. БД и ваше приложение должны рассматриваться как одна система.

Это различие разделяет внепроцессорные зависимости на две подкатегории:

• Управляемые (managed) зависимости — внепроцессорные зависимости, над которыми вы имеете полный контроль. Эти зависимости доступны только через ваше приложение; взаимодействия с ними не видны внешнему миру. Типичным примером является БД приложения. Внешние системы не имеют прямого доступа к вашей БД; они делают это через API, предоставляемый вашим приложением.

• Неуправляемые (unmanaged) зависимости — внепроцессорные зависимости, над которыми у вас нет полного контроля. Взаимодействия с такими зависимостями наблюдаются извне. Примеры - SMTP-сервер и шина сообщений: оба они создают побочные эффекты, видимые для других приложений.

Только неуправляемые зависимости должны быть заменены моками. Используйте реальные экземпляры управляемых зависимостей в тестах.

Резюме

Тестовый двойник - это всеобъемлющий термин, который описывает все виды непригодных к использованию в конечном продукте (non-production-ready), фейковых зависимостей в тестах.

• Существует пять вариантов тестовых двойников — dummy (манекен), стаб, spy (шпион), мок и фейк, которые можно сгруппировать всего в два типа: моки и стабы.

• Spies функционально такие же, как и моки; dummy и фейки выполняют ту же роль, что и стабы.

Различия между моками и стабами:

• Моки помогают имитировать и изучать исходящие взаимодействия: вызовы от SUT к его зависимостям, которые изменяют состояние этих зависимостей.

• Стабы помогают имитировать входящие взаимодействия: для получения входных данных SUT обращается к своим зависимостям.

• Проверка взаимодействия со стабами всегда приводит к хрупким тестам.

• Тестовые двойники, заменяющие команды CQS, являются моками. Тестовые двойники, заменяющие запросы CQS, являются стабами.

Мок-как-инструмент - это класс из библиотеки моков, который вы можете использовать для создания мока-как-тестовый-двойник или стаба.

Внепроцессорные зависимости можно разделить на 2 подкатегории: управляемые и неуправляемые зависимости.

• Управляемые зависимости - это внепроцессорные зависимости, доступные только через ваше приложение. Взаимодействия с управляемыми зависимостями не наблюдаются извне. Типичным примером является БД приложения.

• Неуправляемые зависимости - это внепроцессорные зависимости, к которым имеют доступ другие приложения. Взаимодействия с неуправляемыми зависимостями наблюдаются извне. Типичные примеры - SMTP-сервер и шина сообщений.

• Связь с управляемыми зависимостями - это детали реализации; связь с неуправляемыми зависимостями является частью наблюдаемого поведения вашей системы.

• Используйте реальные экземпляры управляемых зависимостей в интеграционных тестах; замените неуправляемые зависимости моками.

• и