Привет. Хотелось бы рассказать о приложении для организации мок-сервера Mockoon. Это довольно удобная и мощная программа, но в русскоязычном сегменте интернета про нее ничего не нашлось, поэтому решил поделиться опытом использования с примерами возможностей.

Работаю тестировщиком мобильных приложений и для проверки UI часто необходимо менять данные, чтобы посмотреть отображение элементов в разных состояниях. Например, в приложении есть экран с информацией о заказе (приходит с бека в формате JSON), у которого отображается номер, цена, состав заказа, еще какая-то информация. И количество состояний для одного и того же поля может быть разным: где-то заказ с промокодом, скидкой, купоном, где-то количество товаров разное, товар был заменен, убран из заказа, поле может быть, а может и отсутствовать. Либо просто добавили новое поле и нужно посмотреть, как оно работает, а бек еще не готов присылать нам это поле. Чтобы каждый раз не искать готовый заказ с подходящими условиями или делать его через бд (иногда такой возможности и нет), можно подменить ответ, указав нужные значения.

Для таких целей обычно используют программы типа Charles или Proxyman.

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

Поискав, остановился на популярном Wiremock и неизвестном Mockoon.

Посмотрел немного Wiremock - не понравилось управление, разбираться с настройками не стал и переключился на Mockoon.

Mockoon – кроссплатформенное приложение с визуальным интерфейсом, бесплатно для использования, с платной поддержкой. Есть версии для Windows, Mac, Linux.
С помощью него можно легко настроить мок-сервер для отладки и тестирования rest запросов. Так же тут можно хранить коллекцию моков на разные условия и генерировать нужные данные. Можно поднять настроенную коллекцию в докере. Плюс есть поддержка правил срабатывания и генераторы данных.

Интерфейс

Дока с описанием от разработчиков https://mockoon.com/docs/latest/gui-cheat-sheet/

Все скрины делались в версии для Mac, в версии 1.20, поэтому могут быть отличия в других платформах.

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

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

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

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

Мок может быть отдельным файлом (от чего хотелось уйти) и частью коллекции.

Основные кейсы

Рассмотрим пример составления мока для самого простого случая.

Если что, вот то же самое от разработчиков.

К примеру, наше приложение обращается с запросом GET на адрес https://www.application.com/path/to/profile и нам нужно подменить только этот запрос.

Создаем новую коллекцию Example и переключаемся на нее

На вкладке Settings указываем порт, на котором будет работать наша коллекция с моками. По умолчанию подставился 3001.

Далее на вкладке Proxy указываем домен для обращения и включаем галку Enable proxy mode – с ней запросы будут идти минуя Mockoon, если в коллекции нет подходящих для ответа, и соответственно мокаться не будут.

Переключаемся на вкладку Routes. Тут указываем тип запроса GET, ендпоинт path/to/profile и тело ответа. Код ответа оставим 200.

Все готово, осталось запустить и проверить.

Нажимаем кнопку с зеленым треугольником Start server – у коллекции появляется индикатор активности. Если нажать на иконку со стрелкой справа от адреса запроса, в браузере откроется наш мок по адресу http://localhost:3001/path/to/profile, соответственно localhost можно поменять на ip нашего компьютера в сети, например 192.168.1.10 и обращаться из локальной сети, результат будет тем же.

http://localhost:3001/path/to/profile

На вкладке Logs при необходимости можно посмотреть детальную информацию по запросам, проходящим через Mockoon.

Теперь, если нужно увидеть ответ в приложении, осталось настроить перенаправление через наш ip и порт (к примеру на http://192.168.1.10:3001) и выполнить запрос, по адресу path/to/profile откроется наш мок. В то же время все остальные запросы будут идти мимо как обычно.

Перенаправление можно настроить через те же Charles или Proxyman.

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

Использование встроенных функций

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

К примеру, в приложении есть метод получения заказа по id (orders/{id}) и мы хотим видеть разные данные, в зависимости от запрашиваемого id заказа: для orders/1 ответ будет статичным а для остальных значений id (например orders/2) данные в ответе будут генерироваться.

По аналогии с запросом из первого примера, добавим в коллекцию новый запрос orders/:id

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

Для создания правил доступны данные из адреса запроса, параметров, тела, заголовков, куки.

На вкладке Rules добавим само правило: если значение в пути для id будет = 1 то придет ответ из Response 1, который запишем на вкладке Status&Body

Теперь добавим ответ для значения, если id будет отличен от 1.

Для этого рядом с Response 1 нажмем на плюс (Add response) – добавится еще один вариант ответа. В нем так же добавим правило, но теперь для id != 1, нажмем на восклицательный знак для инверсии правила.

Добавляем новый Response 2 c кодом ответа 200

В теле ответа будем генерировать данные. В Mockoon используется библиотека Faker и собственные хелперы для генерации данных. Пропишем такой пример на вкладке Status&Body:

"id": {{urlParam 'id'}}, "name": "{{faker 'name.firstName'}}", "price": {{int 1000 3000}}, "delivery": {{oneOf (array '0' '150' '500')}}, "notiffications": {{boolean}}

Для "id" берем значение из запроса, которое у нас обозначено как :id.

Для "name" через Faker генерится имя.

Для "price" берется произвольное число из диапазона от 1000 до 3000.

Для параметра "delivery" произвольно берется значение из доступных: 0, 150 или 500.

У параметра "notiffications" булевый тип, для него сгенерится true или false.

Полный перечень есть на странице документации.

Теперь, если сделать запрос на /orders/1, то в ответе буде статичный ответ из Response 1.

А если запрос будет к примеру на /orders/23, то в ответе будет Response 2 и сгенерированы примерно такие значения:

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

Ещё пара моментов

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

Для одного ендпоинта можно добавить множество вариантов ответа, с разными данными, статусами, условиями срабатывания.

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

Когда в запросе передаются параметры, например cart?update=false&promo=example, то в путь записываем только cart а остальные значения выносим в правила.

Возможно, приложение будет ругаться на отсутствие токена авторизации в ответе мока, можно извлечь его из запроса и подставить в ответ. Для этого на вкладке Headers добавим хедер Authorization и значение {{header 'Authorization'}}

Если какой-то запрос в коллекции не нужен, то его можно выключить выбрав Toggle.

После включения/выключения запроса, чтобы изменения заработали, нужно перезапустить сервис желтой стрелкой.

Развертывание сервиса в докере

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

Для создания образа на удаленной машине выполнить

sudo docker run -d --mount type=bind,source=/home/user/mocks/Example.json,target=/data,readonly -p 3001:3001 mockoon/cli:latest --data data --port 3001

где source - адрес до файла с моками

порт 3001, который̆ использовался при настройке в Mockoon и на котором будут доступны моки

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

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

Заключение

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

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

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

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

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

Спасибо за внимание.