В статье расскажу о том, как тестировал микросервис с помощью мок-данных или моков (mock data). Объясню, что это такое, почему их использовал, как создавал и к каким выводам пришел.

В чем особенность?

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

Почему использовались моки?

Мок-данные использовались для тестирования микросервиса по нескольким причинам. Одна из них – необходимость проводить тестирование независимо от других микросервисов или внешних систем. Таким образом, появлялась возможность находить и исправлять любые ошибки не затрагивая другие компоненты.

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

Следующая причина – последовательность. Необходимо быть уверенным, что тесты микросервисов последовательны и переиспользуемы. Таким образом можно было бы использовать одни и те же мок-данные для разных тестов или сред, не беспокоясь об изменениях данных или несоответствиях. Также их можно было хранить и повторно использовать для будущих тестов или в качестве справочника.

Последняя причина – эффективность. Создание и использование мок-данных «по запросу», не дожидаясь получения реальных данных из других источников или систем, а также снижение стоимости и сложности настройки и обслуживания реальных источников данных или систем для целей тестирования, позволило повысить эффективность и скорость тестов для микросервисов.

Как создавались и использовались мок-данные?

Для создания моков использовался mockserver в Docker контейнере. Mockserver – это инструмент, позволяющий имитировать практически любую систему или сервис, от которых вы зависите, через HTTP или HTTPS. Его можно использовать для тестирования микросервисов путем моделирования их нисходящих зависимостей и записи запросов и ответов, которые проходят через них. А также для проверки того, что микросервис соответствует определенным ожиданиям, таким как отправка правильных запросов или получение ожидаемых ответов.

Mockserver на базе Docker контейнера предоставляет REST API для получения ожидаемых данных и управления ими, а также веб-панель мониторинга для их просмотра и редактирования. Для взаимодействия с Mockserver API можно использовать клиентскую библиотеку или инструмент командной строки.

Чтобы настроить и запустить контейнер с mockserver, устанавливаем Docker на компьютер и убеждаемся, что он запущен. Загружаем образ mockserver из Docker Hub, выполнив следующую команду:

docker pull mockserver/mockserver

Создаем файл docker-compose.yml в каталоге проекта со следующим содержимым:

version: "3"
services:
  mockserver:
    image: mockserver/mockserver
    ports:
      - "1080:1080"
    environment:
      MOCKSERVER_INITIALIZATION_JSON_PATH: /config/initializerJson.json
      MOCKSERVER_LOG_LEVEL: INFO
    volumes:
      - ./config:/config

Этот файл устанавливает сервис с именем mockserver, который использует образ, скачанный из Docker Hub, устанавливает порт хоста (для панели мониторинга) и порт контейнера равный 1080 и задает уровень журнала равным INFO. Создает и привязывает том из текущего каталога (./config) к /config внутри контейнера, настраивает инициализатор ожиданий JSON.

Ожидание состоит из двух частей: соответствия запроса и генератора ответа. Первая часть определяет критерии для входящих запросов, такие как метод, путь, заголовки или тело, а вторая – как генерировать ответ для соответствующих запросов, таких как код состояния, заголовки, тело или задержка.

Итак, наш микросервис зависит от другого сервиса, который предоставляет информацию о пользователе. Чтобы эмулировать данные от стороннего сервиса, в каталоге config создаем файл initializerJson.json со следующим содержимым:

[
  {
    "httpRequest": {
      "method": "GET",
      "path": "/controller/777"
    },
    "httpResponse": {
      "statusCode": 200,
      "headers": [
        {
          "name": "Content-Type",
          "values": [
            "application/json"
          ]
        }
      ],
      "body": {
        "id": 777,
        "name": "Test Controller",
        "description": "Description for Test Controller"
      }
    }
  }
]

Где httpRequest это ожидание со следующим соответствием запросу:

"httpRequest": {
  "method": "GET",
  "path": "/controller/777"
}

Оно подходит для GET-запроса с путем /controller/777.

А httpResponse ­­­– генератор ответа:

"httpResponse": {
    "statusCode": 200,
    "headers": [
        {
            "name": "Content-Type",
            "values": [
                "application/json"
            ]
        }
    ],
    "body": {
        "id": 777,
        "name": "Test Controller",
        "description": "Description for Test Controller"
    }
}

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

Следующей командой запускаем службу mockserver из каталога проекта, куда до этого положили файл docker-compose.yml:

docker-compose up -d

Данная команда создает и запускает контейнер с mockserver в фоновом режиме. Убеждаемся, что контейнер запущен и к нему можно получить доступ из панели мониторинга mockserver, открыв http://localhost:1080/mockserver/dashboard в браузере. При создании мок-данных для зависимостей микросервиса, можно использовать данную панель управления, чтобы посмотреть ожидания для каждой зависимости.

Как проверялось ожидаемое поведение микросервиса?

Чтобы проверить ожидаемое поведение микросервиса, использовались два подхода:

1. Postman для отправки API запросов к микросервису и проверки того, возвращаются ожидаемые ответы или нет.

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

Например, у микросервиса есть конечная точка /controller/{идентификатор контроллера}, которая возвращает некую информацию о контроллере из имитируемой службы. Чтобы протестировать эту конечную точку, отправляем следующий GET запрос в Postman:

http://127.0.0.1:1080/controller/777

И получаем следующий ответ:

Затем открываем панель мониторинга mockserver и проверяем, был ли записан запрос и ответ для имитируемого сервиса:

Какие выводы?

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

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