Путь к успеху никогда не бывает легким, а пункт назначения никогда не является самим успехом. Главное — это сам путь.

В этой статье я хочу познакомить читателей с одним из необычных open source проектов, над которым мы работаем последние несколько месяцев. Мы — это Нил и Аравинд [Neel и Aravind], команда из двух молодых инженеров. Нас объединяет страсть к непрерывному обучению и созданию проектов для сообщества.

Наш проект посвящен разработке Mimock — инструмента, который помогает создавать моки REST API эндпоинтов для тестирования UI-приложений локально или в CI/CD-пайплайнах. Mimock представляет собой основанное на перехвате данных решение, позволяющее разработчику создавать или обновлять моки без необходимости перезапускать приложения.

Почему мы создали Mimock

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

В настоящее время наблюдается явная тенденция контрибьютить в проекты с открытым исходным кодом. Инженеры по всему миру стали вносить все больший вклад в различные проекты, и даже крупные технологические компании теперь играют более активную роль на благо open source сообщества. Мы также планировали разработать один из таких инструментов — не только полезный, но и простой в использовании. В процессе мы постарались выявить проблемы, с которыми сталкиваются разработчики, и найти пути их решения.

Проблему сформулировали следующим образом:

Что если разработчик или QA-инженер сможет сделать мок REST API эндопинта без написания кода реализации самого мока?

Это и стало первым шагом на пути к созданию концепции нашего особенного инструмента.

Mimock разработан для создания моков REST эндпоинтов без необходимости поддерживать код моков. Приложение представляет собой пользовательский интерфейс на базе React, который может использовать для создания и поддержки моков любой человек без опыта кодирования.

Если UI-приложение разработано с настраиваемым источником для бэкенда, с которым оно работает, то можно подключить Mimock для обслуживания требуемого ответа. Это применимо также и для бэкэнд-сервисов, которые для обработки запроса полагаются на другие API или сервисы.

В качестве примера можно привести следующие сценарии использования:

• Если пользовательский интерфейс (веб- или мобильный) полагается на внешний API, вызовы которого являются дорогостоящими, то вместо него можно использовать Mimock для имитации этого API и передачи ответа на следующие уровни или CI/CD-пайплайны, которые запускают автоматизированные UI-тесты.

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

Фичи

Перечислю уникальные фичи утилиты Mimock:

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

• Отсутствие повторного развертывания: моки можно добавить в режиме реального времени, при этом перезапускать приложение не требуется. Моки создаются/обновляются на ходу, что обеспечивает ускорение разработки и сокращение времени выполнения работ.

• Управление доступом: платформа использует ролевую пользовательскую модель. Администратор может назначать роли пользователям для настройки и ограничения доступа.

• Поддержка текстовых и бинарных типов ответов: можно настроить мок так, чтобы он выдавал обычный JSON-ответ или файл изображения JPEG, или даже желаемый PDF-документ.

Настройка мока

Мы создали Spring boot веб-приложение, в котором разместили логику управления и хранения моков REST API эндпоинтов. Приложение на основе запроса клиента/UI приложения выполняет поиск и вызов хранимого мока REST API.

Ниже приведен один из сценариев использования нашей платформы.

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

Поток диаграмм запросов и ответов до и после использования Mimock показан и объяснен следующим образом.

Фактическое взаимодействие без mimock:

UI-приложение обычно посылает запрос на REST API эндпоинт, представленный бэкенд-сервисом. На основе API-запроса, отправленного клиентом, бэкенд-сервис выполняет бизнес-логику и отправляет соответствующий ответ обратно в пользовательский интерфейс.

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

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

Команда разработки пользовательского интерфейса также занимается тестированием, которое включает в себя тестирование эндпоинтов и анализ поведения пользовательского интерфейса с помощью автоматизированных тестов, таких как Selenium или Puppeteer. Эти тесты выполняются в основном в CI/CD-пайплайне и сильно зависят от бэкенд-сервиса.

Mimock выступает в качестве замены этих backend-сервисов, развернутых вместе с UI-приложениями в средах разработки или тестирования. Однако поведение развертывания в интеграционных средах, где используются как реальные фронтенд-, так и бэкенд-сервисы, остается прежним.

На этапе разработки идеи проекта лучше всего планировать поведение API задолго до его реализации. Большинство команд принимают решение о контракте API, который будет включать в себя детали запроса и ответа. Это большое преимущество для нас — почему бы не использовать его в автоматизированном интеллектуальном режиме с помощью инструмента?

После включения Mimock:

Платформа Mimock заменяет собой весь бэкенд-сервис. Здесь соответствующее клиентское/UI-приложение посылает запрос, а Mimock перехватывает его и отвечает на основе динамических параметров, таких как query-параметры, тело и заголовки запроса.

Пошаговое объяснение:

1. Команда использует Mimock для хранения тестовых REST API эндпоинтов (либо через REST API, либо через пользовательский интерфейс).

2. Они могут хранить несколько типов поведения моков, которые они ожидают, а также соответствующие детали запроса и ответа, связанные с ними.

3. Теперь всякий раз, когда UI-приложение посылает запрос, Mimock перехватывает его, и на основе пути выдает соответствующий ответ.

Таким образом, Mimock устраняет зависимость от бэкенд-сервиса для REST API эндпоинтов.

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

Автоматизированные UI-тесты можно запускать в CI/CD-пайплайнах с помощью Mimock, либо запуская экземпляр Mimock внутри пайплайна, либо размещая Mimock как внешний сервис.

Технологический стек

Стек включает в себя:

• Spring Boot — для основного бэкенда;

• React — для интуитивного пользовательского интерфейса;

• Postgres — для хранения моков и информации о пользователях;

• Docker — для дистрибьюции.

Пункты нашей дорожной карты:

• Импорт моков пачками;

• Regex-сопоставление для динамических полей в параметрах url, теле и заголовках запроса;

• Генерирование динамического текстового ответа с использованием полей из запроса (параметров url, тела или заголовков запроса);

• Клонирование моков;

• Группировка моков в папки/категории;

• Предварительный просмотр файлов для моков, отвечающих бинарными данными.

и еще многое другое в будущем.

В заключение приглашаем QA-инженеров на открытый урок, который пройдет сегодня вечером — на нем мы рассмотрим Java Generics для обобщенного программирования и их роль в автоматизации тестирования. Также кратко рассмотрим типичный тест-дизайн в UI автоматизации и применение Java Generics в Navigation pattern. Записаться на урок можно на странице курса "Java QA Engineer. Professional".