Всем привет! В качестве вступления - краткая информация о том, что такое mock-сервисы и зачем они нужны.

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

1. Изолировать тестируемый код от внешних факторов

2. Упростить тестирование в контролируемых условиях

3. Эмулировать сценарии, которые сложно воспроизвести с реальными сервисами (ошибки, задержки, специфичные данные)

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

Что это для нас значит:

• Постоянно приходится подбирать тестовые данные актуальные во внешних для нас сервисах

• Зависимость от сторонних команд и стабильности их продуктов

• Сложность в проверке ошибок внешних систем

Чем обычно пользовались

Castlemock - https://castlemock.github.io/

Из плюсов: Единый web-интерфейс и адрес для всей команды, можно импортировать WSDL, можно проксировать запросы, можно вести несколько проектов одновременно

Зачем проксировать? Чтобы не перенастраивать приложение, настроили весь трафик в Castlemock + настроили проксирование. Потребители не страдают, мы видим весь трафик. Можем в любой момент включить статичные ответы, добавить задержку, поменять статус-код и т.д.

Из минусов:

• Не всегда стабильная работа - в режиме проксирования, если сторонний сервис упал или недоступен, то Castlemock будет просто падать, роняя всю работу и с другими проектами.

• Нет условных ответов - есть некая рандомная стратегия ответов, но нет возможности написать условие: "если user = 1, то отвечай так, на все остальные по-другому"

• Устаревший интерфейс - сложная навигация по эндпоинтам, плохой поиск логов и т.д.

SoapUI

Из плюсов: Можно импортировать wsdl, можно Groovy кодом обрабатывать ответы. и вроде все

Из минусов:

• Плохо работает поднятие нескольких проектов одновременно

• Нет проксирования

• Нет единого веб-интерфейса - приходилось поднимать на Windows-машине отдельной и по RDP ходить включать, выключать, менять ответы

Иногда мы занимались очень грязными вещами, мы проксировали трафик из Castlemock в Soap UI чтобы добавить условие, естественно это все дико неудобно и не так стабильно

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

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

И мы разработали Mock Service - современную систему для создания и управления mock API с веб-интерфейсом. Основная идея - объединить лучшее из Castlemock и SoapUI, но сделать это удобно и универсально.

Важный дисклеймер. Код проекта практически полностью создан нейросетью. Действительно Cursor и claude-sonet-4 отлично справились с этой задачей. Основная часть проекта была выполнена за 1-2 дня + потом уже исправлялись баги по результатам внедрения (если суммировать, то примерно еще 1-2 дня ушло на исправление багов)

Ссылка на репозиторий с продуктом - mock.service

Архитектура решения (Архитектура выбиралась таким образом, чтобы я смог понять о чем пишет claude-sonet)

Backend — FastAPI на Python с SQLite базой данных. Логи пишутся просто в структированный файл, а для настроек самих сервисов sqllite хватает за глаза

Frontend — React + TypeScript + Ant Design. Современный интерфейс, который не стыдно показать.

Для развертывания Docker + docker-compose - всё упаковано в контейнеры, запускается одной командой.

Расскажу про функционал

После создания ендпоинта есть на выбор 3 стратегии ответов. Стратегии ответов можно менять «на горячую» в интерфейсе продукта

1. Проксирование — как и в Castlemock сделали проксирование трафика через сервис. Видим весь трафик, можем добавить задержки, не падаем, если внешний сервис недоступен

2. Статичные ответы — возвращаем заранее настроенные данные (xml или json). Можем использовать параметры, которые приходят в URL ендпоинта. Например /api/v1/users/{id} потом взять ИД и указать в теле ответа

3. Условная логика — с помощью python кода мы можем распарсить запрос к сервису и вытащить нужны данные. На основании этих данных мы можем построить условия и вернуть потребителю ответ. Аналогично можно использовать параметризацию из URL или python кода. Так же в условном режиме мы тоже можем проксировать. Например конкретным пользователя мы отвечаем 404 на любой запрос, а всех остальных уже пускаем по обычному маршруту

Что еще важного:

1. Универсальная группировка ендпоинтов в интерфейсе. Можно группировать все сервисы по путям, которые мы указали. Можно по префиксу в имени. Получается удобная навигация (у нас сейчас около 900 настроенных ручек и без группировки стало просто неудобно)

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

3. Да, часто мы каждый отдельный метод настраиваем как отдельную ручку в сервисе. НО мы можно использовать параметризацию. Например /api/v1/{*} и мок будет выполнять правила для всех, кто начинает свое обращение по пути /api/v1/. Или вот так /api/v1/{name}/service/{id} и т.д. в интерфейсе есть подсказки для этого

4. Система логирования. Все запросы, которые проходят через мок логируются. Просматривать их можно в реальном времени (сделаны web-сокеты) можно останавливать и фильтровать по сервису, по имени, по времени и т.д.

5. Импорт из Swagger/OpenAPI схем. Проверял на swagger 2.0 схеме все работает, с другими версиями не тестировал, т.к. пока не требовалось. Когда делаем импорт из swagger схемы, то у нас автоматически создаются все методы, которые были описаны в схеме

6. Импорт wsdl схем. Да, поддерживается и soap протокол. Тут пришлось повозиться, оказывается не все soap сервисы одинаково хороши. В некоторых сервисах имя метода было написано в заголовке soapAction, в некоторых в content-type/action, а у других не подписано нигде и нужно вытаскивать нужный метод из Body. Код парсинга soap методов получился довольно костыльный и путанный, но он работает (проверено на 20 различных сервисов разработанных разными командами)

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

8. Можно использовать без фронтенд части, есть swagger документация для бекенда приложения

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