Привет! Меня зовут Ольга Инеева, я ведущий инженер по обеспечению качества в Т-Банке. Расскажу о проблемах тестирования интеграции и об инструменте для мокирования Mockingbird. Мы решили проблему сложных связанных сценариев и хотим поделиться этим знанием. Добро пожаловать под кат!
Проблемы тестирования интеграций
Наше подразделение занимается продуктами, связанными с BNPL-политикой (buy now, pay later). Это такие продукты, как автокредит, ипотека, сервис «Долями», потребительские кредиты и другое. У нас много интеграций — как внутрибанковских, так и внешних. На стабильность работы внешних систем мы чаще всего не можем повлиять.
Мы столкнулись со множеством проблем при тестировании этих интеграций:
Сторонняя система еще не реализована, а мы уже хотим протестировать взаимодействие с ней.
Тестовый контур приложения, с которым мы интегрируемся, работает нестабильно.
Долгий ответ внешнего сервиса. Можно отвлечься на другие задачи, пока ждешь ответа, а писать автотесты через Thread.sleep(N) — не лучшая идея.
Сложность в получении ответа, для которого нужны специфические данные.
Необходимость ручных действий соседней команды. Неудобно постоянно просить коллегу нажать кнопку или прописать данные.
Нехватка тестовых контуров. Бывают случаи, когда тестовый контур у системы отсутствует, или каждый поход в нее платный, что сильно сокращает возможности тестирования.
В подобных случаях лучше использовать моки. Моки, или заглушки, –— это эмуляция сервиса, с которым у нас есть интеграция. Главное правило: не увлечься ими, протестировать в рамках e2e-сценариев и живой интеграции, иначе рискуем словить непредвиденный баг.
Плюсы мокирования:
Тесты становятся быстрее. Интеграции на тестовых контурах отвечают с задержкой, а развернутый мок-сервер — практически мгновенно.
Возможно сэмулировать все тестовые случаи.
Растет уровень доверия к тестам.
Минусы:
Риск словить баг на реальной интеграции.
Необходимо поддерживать моки в актуальном состоянии. Можно попасть в ситуацию, когда другой сервис обновил контракт в одностороннем порядке, а тесты остались «зелеными». От этого нас могут защитить контрактные тесты, но это уже совсем другая история.
Уровень доверия к тестам
Представьте, что в ваших тестах используется реальная интеграция, а не моки. Вы смотрите утром отчет по ночному прогону, и он выглядит так:
Вы думаете о том, почему упали 3 теста. Причин может быть много: у стороннего сервиса мог быть сбой, возможно, есть баг со стороны интеграции или тест действительно нашел проблему нашего приложения.
Моки решают эту проблему: когда падают мокированные тесты, скорее всего, причина в баге нашего приложения. При условии стабильности инфраструктуры и соблюдения актуальности моков. Так мы начинаем больше доверять результатам наших тестов.
Я собрала самые используемые решения для мокирования в таблицу.
Mountebank | WireMock |
REST | REST |
SOAP | SOAP |
gRPC (плагин) | Webhooks |
WebSocket | Мокирование цепочки вызовов |
Нам не хватило функций в этих популярных решениях:
Эмуляции работы с брокерами сообщений.
Поддержки сложных связанных сценариев, в том числе между HTTP-моками и моками для брокеров сообщений.
Приоритизации моков: хочется иметь и постоянный контур для Happy Path, и возможность тестировать различные сценарии с помощью моков, не ломая при этом существующие моки и сценарии.
И хотелось делать все с помощью одного инструмента.
Mockingbird
Mockingbird — open-source-инструмент для мокирования, созданный Даниилом Смирновым, который работал архитектором в нашей компании.
До августа 2023 года работа велась в репозитории корпоративного аккаунта. К сожалению, аккаунт переведен в статус Archived, поэтому развитие сервиса происходит в рамках форка.
Инструмент умеет делать эмуляции:
HTTP-сервисов;
шинных сервисов;
gRPC-сервисов.
Для решения проблемы с приоритизацией моков есть механизм конфигурации — поле Scope в заглушке. В зависимости от выбранного типа Scope заглушка будет иметь меньший или больший приоритет при поступлении запроса на URL, указанный в заглушке.
Таблица с видами Scope, их приоритетами и областью применения
Scope | Persistent | Ephemeral | Countdown |
Приоритет | Наименьший | Средний | Наивысший |
Автоматическое удаление | Нет | Да, через неделю | Да, каждую ночь |
Применение | Обеспечение автономности тестового контура | Временное изменение постоянного (persistent) мока | Конкретный тестовый сценарий |
С помощью этого механизма можно создать два мока с разным поведением для одного endpoint: один мок — с конфигурацией Persistent для Happy Path, и мок с конфигурацией Countdown, который будет реализовывать другой сценарий.
Mockingbird позволяет создавать моки двумя способами:
используя API;
через UI.
Рассмотрим механизмы инструмента при работе с HTTP-сервисами и брокерами сообщений.
Эмуляция REST-сервисов
Инструмент валидирует тело поступившего на заглушку запроса в режимах:
no_body — запрос должен быть без тела;
any_body — тело запроса должно быть не пустым, при этом оно никак не парсится и не проверяется;
raw — тело запроса не парсится, проверяется на полное совпадение с описанным в моке телом запроса;
json — тело запроса должно быть валидным JSON и проверяется на строгое соответствие с описанным в моке json;
xml — тело запроса должно быть валидным XML и проверяется на строгое соответствие с описанным в моке xml;
jlens — тело запроса должно быть валидным JSON и валидируется по условиям, описанным в моке, не требуя полного соответствия;
xpath — тело запроса должно быть валидным XML и валидируется по условиям, описанным в моке, не требуя полного соответствия;
web_form — тело запроса должно быть в формате x-www-form-urlencoded, валидируется по условиям, описанным в моке;
multipart — тело запроса должно быть в формате multipart/form-data format. Такой тип моков специфичен, об этом можно почитать в Readme.
Можно сравнивать параметры запроса на равенство и неравенство, больше или меньше числа, соответствие регулярному выражению, проверять длину значения и существование поля.
Mockingbird поддерживает режимы ответа: raw, json, xml, binary, proxy, json-proxy, xml-proxy. Режимы запроса и ответа независимы, то есть заглушка может ожидать JSON, а отвечать в формате XML.
Рассмотрим примеры несложных REST-заглушек. Здесь будет полезен список обязательных полей в HTTP-моке:
Name — название заглушки;
Method — HTTP-метод, используемый в запросе;
Path — эндпойнт, который хотим замокировать;
Scope — конфигурация (persistent/ephemeral/countdown);
блок Request — как валидировать запрос;
блок Response — как отвечать на запрос;
Mode — режим валидации запроса (если находится в блоке Request) и режим ответа (если находится в блоке Response);
Headers — заголовки запроса и ответа;
Delay — задержка отдачи ответа (до 30 секунд).
Пример 1. Валидация по телу запроса. Для создания мока, который срабатывает на определенное тело, нужно описать условие в блоке request. Пример реализует следующую логику: если запрос, поступивший на эндпойнт с окончанием /stubBody, имеет в теле {“id”: 42}, сработает заглушка. Она отправит статус-код 200 и тело {“field”: “Hello from body trigger mock!”}.
В моке используется режим нестрогого соответствия для json — jlens, поэтому для выполнения мока достаточно наличия поля ID со значением 42 в теле запроса. Если бы был выставлен режим строгого соответствия, json, заглушка сработала бы только в случае, если тело запроса было бы строго равно {“id”: 42}.
Пример 2. Валидация запроса по query-параметру. Отличие от валидации по телу запроса только в условии срабатывания заглушки. Она срабатывает, если значение query-параметра data, равного 1234, прописано в блоке Query, а не Body и выбран режим No_body, так как мы ожидаем запрос без тела. В ответе мы используем значение поступившего query-параметра, используя конструкцию $query: заглушка вернет имя параметра и его значение.
Пример 3. Проксирующий мок. Если не хватает тестовых контуров, хочется иметь возможность тестировать и на реальной интеграции, и на моках. Тогда можно создать мок с режимом Proxy: проксирующий мок перенаправляет запрос на другой ресурс. Это поможет не терять на тестовом контуре работу с живой интеграцией. А в случае, когда хочется работать с моком вместо нее, можно создать мок с Scope = Countdown для наивысшего приоритета при выборе подходящей заглушки. Схематично это будет выглядеть примерно так.
Эмуляция шинных сервисов
Mockingbird взаимодействует с брокерами сообщений через HTTP API, благодаря чему теоретически поддерживаются любые возможные MQ.
Наши QA-инженеры работали с RabbitMQ, IBM MQ, Kafka.
Для работы с очередями должна существовать очередь в MQ. Mockingbird читает и пишет в нее, используя, как было сказано выше, HTTP API.
Поддерживаются следующие режимы для валидации входящего сообщения:
raw
jlens
json
xml
xpath
И следующие форматы записи сообщения:
json
xml
raw
Пример сценария для работы с шинным сервисом. Если в очередь, указанную в source (in_queue), поступит сообщение в формате JSON и с полем innerData.abc со значением test, в очередь, указанную в поле destination (out_queue), отправится сообщение {“xyz”: “abc”} в формате JSON.
Callback
Если нужно сделать цепочку вызовов — например, сначала получить ответ REST-сервиса, а затем послать сообщение в Kafka или отправить запрос по HTTP, — пригодится механизм Callback. Он позволяет выполнить дополнительное действие после основного.
Поведение после получения ответа заглушки описывается в блоке Callback. Тип Callback регулируется полем Type, которое может принимать два значения: HTTP и Message — для работы по HTTP или с брокером сообщений соответственно.
Пример с Callback по HTTP. Помимо основных полей заглушки в блоке Callback нужно указать, на какой URL обратиться, метод, тело запроса и заголовки.
Пример с Callback в брокер сообщений. В блоке Callback указан тип = Message, очередь, куда нужно положить сообщение (поле Destination), и само сообщение в блоке Payload.
Генерация данных
Иногда нужно сгенерировать случайное значение и сохранить или вернуть его в результате работы мока. Это можно сделать с помощью блока Seed, положив туда сгенерированную строку /int/long/uuid/date/dateTime.
Для генерации данных используется блок Seed. Для определенного типа данных используется соответствующее указание. Например, для создания случайной строки длиной 20 символов будет использоваться команда %{randomString(20)}, а сгенерированное значение присваивается полю SomeId.
Далее сгенерированные значения можно использовать через "$seed.названиеПоля", например "${seed.someId}".
Состояния, state
Есть сценарии, когда требуется моделировать разные ответы при запросе на один и тот же URL. Для решения подобных ситуаций в Mockingbird используется состояние, или State. Состояние — документ в MongoDB с данными, которые используются в качестве условия для выполнения заглушки.
В описании состояния могут присутствовать два блока: State и Persist. State отвечает за чтение, а Persist — за создание и обновление состояния.
Логика блоков:
если есть блок Persist, но нет блока State, создаем новое состояние;
если есть блок Persist и блок State, обновляем состояние, которое указали в блоке State.
Рассмотрим сценарий: эндпоинт принимает на вход ID карты и возвращает статус готовности: «Одобрено», «Подтверждено» и «Выдано».
Нужно создать три мока. Первый будет отвечать статус-кодом 200 и статусом «Одобрено», при этом создаст состояние с помощью блока Persist. В состоянии будет поле _cardId со значением номера карты в запросе и поле Status со значением Approved.
Второй мок должен вернуть статус «Подтверждено». В блоке State ищется состояние с _cardId, который совпадает с ID карты из запроса и статусом Approved. Второй мок будет отвечать статус-кодом 200 и статусом «Подтверждено». Блок Persist обновит состояние: поле Status изменится с Approved на Confirmed.
Третий мок должен вернуть статус «Выдано». Логика идентична второму моку: поиск State с номером карты, который совпадает с картой из запроса, и Status со значением Confirmed. Блок Persist обновит состояние: в поле Status значение изменится на Issued и отправится статус-код 200 со статусом «Выдано».
Помимо подобного сценария State можно использовать для мокирования цепочки вызовов или других ситуаций, где требуется запоминать данные и затем манипулировать ими в других заглушках.
Какие заглушки и для чего мы создаем
Для ручного тестирования Mockingbird чаще всего используется для создания:
вечных (scope = persistent) HTTP-моков;
вечных сценариев для MQ.
Это позволяет иметь полностью замокированный тестовый контур, на котором можно сэмулировать любой тестовый сценарий. Бизнес-заказчик может пройти основной user-story фичи и проверить ее реализацию.
Для автоматизированного тестирования чаще всего используются такие функции:
создание одноразовых (Scope = Countdown) HTTP-моков;
создание одноразовых сценариев для MQ.
Заглушка или сценарий создается под конкретный автотест во время прогона, используя API Mockingbird, и удаляются после использования.
____________________________________
Применение Mockingbird помогло нам:
Решить проблему мокирования работы с шинными сервисами.
Создать стабильный контур, на котором можно пройти Happy Path и другие тестовые случаи. И все это с помощью одного инструмента.
Реализовать сложные связанные сценарии.
В результате команда тестирования легко управляется с актуализацией тестовых сценариев, не переживает из-за флакающих тестов и нестабильности окружающей инфраструктуры.
Буду рада, если мой материал поможет в улучшении стабильности тестового окружения. Надеюсь, что сэкономленное время будет использоваться для улучшения процессов вместо выяснения ложных падений тестов.
А пользуетесь ли вы инструментами для мокирования, и если да, то какими?
