Mock-сервисы для тестирования: How to use + Quick start

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

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

На хабре достаточно статей по данной тематике. Наш QA-инженер–Николай – хочет остановиться на кратком руководстве для старта с общим обзором и примерами по одним из самых популярных инструментов. Дабы была возможность быстро определить перечень используемых инструментов и в дальнейшем продолжить уже их более углубленное изучение.

В данной статье будут приведены примеры с локальным развертыванием. Этот вариант идеально подойдет, если тестируемое приложение развернуто на рабочей машине. Если же стоит задача развернуть заглушку для удаленного сервиса, тут лучше обратиться к девопсам/администраторам. Т.к. политика безопасности не всегда дает доступ на сервер с крутящимся на нем приложением, а перед тем как будущая заглушка начнет отрабатывать – сервис придется перенастроить и перезагрузить. Иными словами сломать. Еще ни одного тестировщика за такие фокусы не похвалили. Потому в данной статье этот вопрос подниматься не будет.

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

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

Итак - приступим.

Старый и всем давно известный инструмент. Пригоден как для тестирования SOUP, так и REST сервисов, автоматизации их проверок и создания заглушек.

Для тех, кто все еще путается:

Рассмотрим на примере REST сервиса. Для SOAP шаги будут идентичными и не вызовут особых трудностей.

При первом запуске автоматически всплывает окно Endpoint Explorer, в котором необходимо указать сам запрос и необходимые для работы заголовки:

Откроем свежесозданную заглушку и скорректируем параметры запроса и ответа. Для этого нужно развернуть список RestMockService и провалиться в иерархии до Response:

Затем двойным кликом открываем сам сервис и запускаем заглушку:

Итак – наша заглушка активна. Теперь ради демонстрации клонируем ранее созданный запрос. В нем нам необходимо изменить хост. По умолчанию заглушка будет запущена на localhost:8080 с сохранением пути названия метода (resource):

Как видно – после запуска стал возвращаться указанный ранее ответ и заголовок.

Теперь осталось только направить тестируемое приложение на наш локальный адрес. Для остановки заглушки необходимо повторно открыть RestMockService и нажать на кнопку Stop:

Добавить новый ключ с именем “MaxUserPort” типа DWORD и десятичным значением 65534.

В более ранних версиях после получения ответа метода была возможность в один клик из контекстного меню поднять заглушку. По умолчанию запуск производился на localhost:8080. Спустя время эту фичу переработали. Теперь заглушка размещается непосредственно на серверах Postman. В бесплатной версии количество таких моков ограниченно 1000 в месяц. Это отлично подходит для демонстрации возможностей или мелкого тестирования, но подход весьма не практичен. Все же, лучшее – враг хорошего. На этом фоне древний SoapUI выигрывает по всем параметрам. Но описать процесс все же стоит.

Для этого нужно:

3. Задать имя mock сервера, указать окружение и скопировать полученный URL:

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

Для корректной работы к получившейся ссылке необходимо добавить API Path:

5. Редактирование заглушки сильно урезано. Иными словами, Response изменить не удастся. Для этих целей придется создавать новую. Если вспомнить про ограничение, описанное выше – получается не самый оптимальный вариант.

6. Также присутствует возможность заглушить метод из ранее сохраненной коллекции, но для этого придется дополнительно создать пример ответа внутри метода. Без этого mock работать не будет. Внутри необходимо указать все те же параметры, что описывались в пункте 2:

Следующий инструмент просто подарок для всех айтишников.

WireMock – это удобный и понятный инструмент. Причём понятный даже для тех, кто только начинает использовать заглушки.

Варианты установки

В данном варианте предоставляется выбор.

Во-первых, инструмент поддерживает Java/Python и может быть добавлен в проект автотестов через зависимости.

Во-вторых, может быть развернут в докере.

В-третьих, может быть установлен отдельным приложением. WireMock Studio — это инструмент, построенный на базе основного движка WireMock, с полным веб-интерфейсом, управлением несколькими фиктивными API и поддержкой OpenAPI и Postman.

Для демонстрации можно обойтись отдельным джарником, без дополнительных расширений.

1. Установка и запуск

Подготовка
Загрузка и установка

$ java -jar wiremock-jre8-standalone-2.32.0.jar

Сервер по умолчанию запускается на порту 8080. В дальнейших примерах будем использовать переменную wireUrl = http://localhost:8080.

2. Создание заглушки

Способ 1

Отправляем POST запрос на url {{wireUrl}}/__admin/mappings/new с телом запроса:

Теперь, если отправить GET запрос на {{wireUrl}}/test/api, то в ответе получим значение заглушки (Success!). Наша первая заглушка готова!

Настройки заглушек могут быть очень гибкими. В качестве url ожидаемого запроса можно указать не только конкретный url, но и urlPattern с помощью regexp.

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

Есть возможность задать ожидаемые:

Способ 2

После первого запуска в директории с джарником были созданы 2 папки: __files и mappings. Добавим в последнюю директорию json файл, в котором руками опишем все требуемые параметры. Для начала зададим общую структуру:

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

Немного усовершенствуем наш мок. Добавим Json в ответе вместо строки, заголовок и куки:

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

Но такой вариант вернет ответ только в том случае, если был передан всего один параметр. В случае, когда передаваемых параметров несколько, и они могут быть подчинены какому-либо закону – целесообразнее использовать следующую конструкцию:

Ну и конечно же желательно обработать кейс, когда пришедший запрос не подходит ни к одному из описанных:

3. Создание заглушки из файла

Вышеизложенные примеры довольно просты и не громоздки, но чаще всего необходимо, чтобы в ответе приходило нечто большее, чем просто “Успех”, а именно толстый json солидных размеров. В качестве ответа в этом случае удобно указывать конкретный файл.

Как уже оговаривалось выше – файлы читаются из директории __files, которая создается автоматически при первом запуске мок-сервера в папке, где лежит джарник. Следует помнить, что путь указывается относительным. Экранировать слеш не нужно. Стоит отметить, что в качестве bodyFileName можно передать не только json, но и xml, и просто текстовый файл.

4. Создание сценариев

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

Например, когда состояние объекта меняется в процессе выполнения теста. Для этого у WireMock есть сценарии:

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

Чтобы посмотреть список созданных сценариев и на каком шаге выполнения находится каждый из них, выполните GET запрос на {{wireurl}}/__admin/scenarios. Для сброса всех сценариев в дефолтное состояние необходимо вызвать {{wireurl}}/__admin/scenarios/reset

Подробнее описано в документации:

5. Recorder

Этому стоит уделить пару строк, но задерживаться особо не имеет смысла. Т.к. вещь может быть весьма полезна, но также и интуитивно понятна. Иными словами – user friendly. После запуска сервера WireMock необходимо открыть страницу с адресом:

http://localhost:8080/__admin/recorder/

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

6. Запуск WIreMock в докере

Образ Docker поддерживает точно такой же набор аргументов командной строки, как и отдельно скачанный джарник. Их можно передать в контейнер, добавив в конец команды:

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

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

Из этого следует, что ситуации, когда приходится их глушить, тоже нередки. Допустим, фронтенд уже готов и задеплоен, а поставщика данных все еще нет. Если наш функционал – это простые уведомления, все не так страшно. А вот к примеру, когда на основе полученных данных, в режиме реального времени строятся графики и тут же на лету меняются, то ждать, когда бэкенд разродиться уже не позволительно. Решено – нужно ставить затычку!

WireMock позволяет работать с вебхуками как из Java, так и в автономном режиме. Рассмотрим последний вариант, т.к. использование внутри Java c Gradle/Maven зависимостями более чем подробно описано в руководстве.

1. Установка и запуск

Помимо основного Jar-файла необходимо скачать Jar-расширение для вебхуков. Хранить оба джарника желательно вместе.

Далее при запуске в командной строке указать наше расширение.

$java -cp wiremock-jre8-standalone-2.33.1.jar:wiremock-webhooks-extension-2.33.1.jar \

com.github.tomakehurst.wiremock.standalone.WireMockServerRunner \

--extensions org.wiremock.webhooks.Webhooks

2. Создание заглушки

По аналогии с ранее проведенными операциями, добавим внутрь json из директории mappings следующее:

Здесь можно заметить, что основные ключи все те же, а вот самый интересный для нас – postServeActions. Именно внутри него определяется поведение нашей заглушки, отличной от простого REST-запроса.

Но вебхук не был бы вебхуком, если бы каждый раз отвечал молниеносно. Для более правдоподобной имитации необходимо прописать задержки. Для этого внутри postServeActions после url добавим следующий блок:

Таким образом можно обеспечить фиксированную задержку при ответе. Для случайной задержки тоже есть решение:

gRPC появился еще в 2015 году на основе протокола HTTP 2.0 и используется преимущественно в высоконагруженных системах. О преимуществах можно говорить долго, но это тема другой статьи. Наша же задача состоит в том, чтобы и их научиться “глушить”.

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

1. Установка и запуск

К счастью, о нас уже побеспокоились и никаких велосипедов изобретать не придется.

Перво-наперво выкачиваем проект с гитхаба.

Для win также понадобится Docker Desktop.

Запуск контейнера:

docker run -p 8888:8888 -p 50000:50000 -v $(pwd)/example/proto:/proto -v $(pwd)/example/wiremock:/wiremock adven27/grpc-wiremock

2. Создание заглушки

Установка заглушки – все то же добавление в json:

Или через POST запрос, используя консоль или любой на вкус REST клиент:

3. Контрольная проверка:

grpcurl -H 'withAmount: 100.0' -plaintext -d '{"user_id": 1, "currency": "EUR"}' localhost:50000 api.wallet.BalanceService/getUserBalance

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

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

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

Пожалуй, самый верный способ имитации – воспользоваться ЯП и создать полноценный сервис. При таком подходе в руках оказывается вся мощь и гибкость ЯП, а если еще повезет, то и бесплатные консультации от разработчиков + бесплатное обучение.

Предварительная подготовка

Для облегчения задачи воспользуемся фреймворком Spring и предварительно сгенерируем свое будущее приложение тут.

В моем случае это будет Maven Project, Spring Boot 2.7.0, Language Java. Metadata оставим без изменений, а вот в Dependencies добавим Lombok и Spring Web.

2. Генерируем и скачиваем проект.

3. Полученный архив распаковываем и открываем через Idea. Даем студии подтянуть все зависимости и настроить среду.

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

Создание контроллера

Контроллер – это и есть имя нашего метода. Иными словами, хвост, за который можно уцепиться. Для примера создадим класс FirstController. Благодаря аннотациям вся основная работа за нас уже была проделана. Стоит уделить внимание следующим:

RequestMapping – все запросы будут иметь в пути указанный префикс.

GetMapping – этим мы сообщаем, что наш запрос GET, который будет доступен по переданному имени, также здесь возможно передать часть пути к ресурсу.

Аналогично GET существуют POST, DELETE, PUT маппинги. Каждая аннотация указывает на принадлежность к определенному типу запроса.

После запуска данный пример вернет строку “success” и код ответа 200 ОК.

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

В данном примере вернется строка с конкатенацией переданных в нее значений. Стоит отметить, что если в вызове не передать paramOne, то наш метод свалится в ошибку. Для paramTwo такого не случится, т.к. этот параметр мы отметили как необязательный.

Описание структуры данных

Метод работает, но на полноценный API не похоже. Нужно возвращать структурированные данные, а не простые строки.

Для этого в пакете DTO создадим класс, описывающий структуру будущего ответа:

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

2. Указать маппинг с указанием структуры

3. Создать экземпляр класса с отсылкой на вложенную структуру

Остановимся на последнем варианте. Для этого в этом же пакете добавим класс Location:

Таким образом, класс FirstMockResp примет вид:

Сервисный слой или контентное наполнение

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

Из контроллера к сервису мы обращаемся через интерфейс. Давайте опишем его:

В конечном счете вернемся к нашему первому контроллеру. Он примет следующий вид:

Запустим приложение для проверки и посмотрим, что вернет контроллер по адресу http://localhost:8080/test/page2

Как видно из примера, полученная структура полностью соответствует описанию.

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

Также есть и способ решения задачи в лоб. Скажем, имея какой-то конечный json, можно отредактировать его value и заменить на переменные, используемые в Postman/Jmeter ${some_variable}. Тогда задача немного меняется. Нам больше не нужно описывать ключи и структуру ответа, т.к. она уже есть, остается только:

Вариантов реализации уйма. Выбирайте наиболее подходящий для вас, в зависимости от поставленной задачи.

Разумеется, WireMock можно спокойно подключить в Java проект для тестов. Использование в JUnit5 и JUnit4 немного отличаются. Конкретные различия указаны в документации:

https://wiremock.org/docs/junit-jupiter/

https://wiremock.org/docs/junit-extensions/

Ниже будет приведен пример использования WireMock в тестах, с использованием наиболее популярного Rest Assured.

Зависимости

Maven

Gradle

Управление mock сервером

После подключения зависимости к проекту управление осуществляется стандартным подходом. Перед началом всех тестов поднимаем сервер заглушек и переопределяем его порт. По завершении сервер отключается:

При использовании JUnit можно обойтись аннотацией Rule. Это позволяет не заботиться о том, как и когда сервер будет остановлен:

Создание mock объекта

Если у вас Spring Boot приложение и вы собираетесь использовать WireMock в тестах, то тут наблюдается проблема при запуске. Решение описано тут.

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

Было полезно? Будем рады обратной связи :)