Как мы на хакатоне написали простой инструмент для интеграционного тестирования

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

Привет, Хабр! 

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

• удобная интеграция,

• простота в понимании и реализации,

• быстрая подмена ответов,

• удобный интерфейс. 

Звучит как идея на хакатон? Так подумали мы и на одном из хакатонов в ATI.SU воплотили её в жизнь. 

Откуда идея

Наша команда разрабатывает страничку сервиса «Проверки ATI.SU». Ее бизнес-логика заключается в получении информации о контрагенте, которая позволяет узнать всё о партнере и не нарваться на мошенников.

В нашем случае проверки бывают двух типов:

• одношаговые: отправил запрос, получил ответ; 

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

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

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

Как с этим взаимодействовать

Пример внедрения мок-сервиса в процесс тестирования представлен на картинке: 

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

Выложили на 1 машину:

«IntegratorOptions»: {   «BaseUrl»: «https://driver.ru/«, },

Выложили на 2 машину:

«IntegratorOptions»: {   «BaseUrl»: «https://mockservice-domain/mockservice/«, },

По итогу, тестировщик, взаимодействуя со второй машиной, имеет возможность создавать и изменять моки, взаимодействуя с первой, проводить завершающее тестирование. 

Как это работает 

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

• группирование созданных моков,

• переключение моков, 

• возврат заготовленных ответов.

Группирование созданных моков 

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

 Теперь его можно найти в поиске в составе группы:

Переключение моков

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

Возврат заготовленных ответов

Основная логика сервиса, также является простой – сервис слушает endpoint, заканчивающийся на «mockservice/», получает из контекста адрес, метод запроса и находит включенный мок, который отдаёт в ответе. 

И это всё? 

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

Приведу пару примеров использования сервиса, появившихся уже после взаимодействия с ним:

1. Возможность написать цепочки методов: Сервис совершает запрос А, потом запрос B и C. На каждый запрос есть возможность задать моки и по-разному их чередовать. 

2. Возможность на основе мок-сервиса, начать выполнять фронтовую задачу, тестируя ее на заранее продуманном контракте. 

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

Заключение 

Мок-сервис не был бы так удобен без своего GUI, что сделало его отличным помощником в тестировании.

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

Пример кода можно посмотреть по ссылке:

https://github.com/gently-whitesnow/MockService/tree/master/MockService.

Может быть, вы писали что-то своё или использовали сторонние решения? Расскажите об этом в комментариях!