Как мы используем сервер заглушек Wiremock на примере E2E тестов

Давайте подробнее рассмотрим, как мы работаем с Wiremock на примере одного из наших проектов.

Система-фасад для системы бронирования

Smart Ticketing (ST) - графический терминал для агентов S7, позволяющая удобным образом управлять бронированиями и делать выписки билетов и услуг.

По большому счёту это «фасад» для системы бронирования ORS. Все данные хранятся там, мы же предоставляем удобный и понятный интерфейс. Например, если агент ищет доступные рейсы, то мы достаём их для него из ORS, а если агент создает бронирование, то мы создаём его в системе бронирования. ST же дополняет все операции спецификой S7. Например, специфической валидацией или же другим источником цен на дополнительные услуги.

Такую систему как ST можно хорошо покрыть E2E тестами, если подменить внешнюю систему ORS неким «заменителем», который будет вести себя также, как ведет себя она.

E2E Тестирование

E2E - тестирование конечных точек (End-to-End), проще говоря, это тестирование всей системы в комплексе.

У таких тестов есть много преимуществ:

• Полнота тестирования: E2E тесты позволяют проверить работу всей системы от начала до конца, эмулируя реальные сценарии использования. Это позволяет обнаруживать проблемы интеграции между различными компонентами системы.
• Обнаружение ошибок: Тестирование конечных точек помогает выявить ошибки или проблемы, которые могут возникнуть из-за взаимодействия между различными частями системы. Например, E2E тесты могут выявить проблемы с передачей данных между клиентом и сервером.
• Поддержание качества: Эти тесты помогают поддерживать высокий уровень качества программного обеспечения, поскольку они проверяют систему с точки зрения пользователя, что помогает предотвратить возможные проблемы, с которыми могут столкнуться конечные пользователи.
• Повышение уверенности: когда все конечные точки системы проходят E2E тестирование успешно, это увеличивает уверенность в том, что система работает корректно и может быть безопасно выкатана в продакшн.

Поговорим подробнее про полноту тестирования. Как уже было сказано выше, при помощи E2E можно проверить работу не только одного вызова, а пользовательских многошаговых сценариев. Для примера самый базовый сценарий: выписка билета состоит из поиска рейсов, получения тарифа, бронирования и собственно покупки билета. И каждый шаг мы делает определённый вызов в ORS. Здесь нам нужно сделать так, чтобы внешняя для нас система вела себя всегда одинаково и предсказуемо.

Чтобы реализовать стабильное тестирование, важно обеспечить независимость тестового окружения от внешних факторов, например, сетевых проблем, состава данных, состояния и т.д., нам нужно заменить ORS чем-то, что мы можем контролировать и что может вести себя как ORS. Здесь как раз и приходит на помощь сервер заглушек.

Wiremock — это open source продукт, созданный для того, чтобы выполнять «грязную» работу, притворяясь кем угодно :) Написан на Java, может работать как отдельно стоящий сервер. Главная его задача - отвечать http-ответами на заранее известные вопросы.

У него очень простое CRUD API для настройки моков:

Wiremock встроен в наши ночные сборки

В 22:00 по расписанию запускается пайплайн TFS, в котором мы собираем текущий master и выкладываем на стенд DEV. Далее действовать начинает Cypress (инструмент автоматизации внешнего тестирования): он настраивает заглушки, прогоняет тесты и после убирает за собой заглушки. Если все теcты проходят, то мы ставим стабильный тег на коммит, что означает, что данная сборка готова к автоматическому деплою.

Statefull поведение

Wiremock поддерживает изменение состояния. Например, в процессе тест кейса Smart Ticketing несколько раз вызывает один и тот же endpoint по зачитыванию бронирования из ORS. При этом вызываемый объект может содержать разные данные в зависимости от стадии процесса, а запрос оставаться одинаковым и его не надо искусственно изменять для каждого шага. Здесь помогут инструкции Wiremock заглушек requiredScenarioState, newScenarioState.

Практика написания E2E тестов

Для того чтобы написать новый тест или актуализировать старый, нужно подготовить набор заглушек для Wiremock. Как это сделать удобно? Ходить к разработчикам отнимет много времени и сил, и результат может быть не точным. Поэтому лучше воспользоваться логами, ведь система подробно может логировать все запросы/ответы к внешней системе в нужном нам формате XML.

Остаётся только удобно разметить эти логи. Мы выбрали подход на основе http-заголовков.

 Браузер при помощи расширения ModHeader может каждый запрос обогащать любым кастомным заголовком. На стороне бэкенда эти заголовки транслируются в атрибуты лог-записи. Таким образом, все записи можно легко найти. Тогда QA-инженер добавляет в свои запросы браузера специальный заголовок X-SMART-Test-Name, в котором содержиться название теста StandartFlowTest. После этого он проходит весь сценарий (для этого выделен специальный стенд QA), который полностью повторяет PROD, то есть по-настоящему взаимодействует со внешней системой.

Заголовок X-SMART-Test-Name используется логгером чтобы разметить логи. После прохождения сценария QA-инженер собирает заглушки про помощи специальной CLI утилиты, которой передаётся название теста StandartFlowTest. Утилита подключается к ELK и получает все логи обмена в контексте пройденого теста, отфильтровывает только нужное, а именно запросы и ответы во внешнюю системы и их порядок, и формирует готовый набор файлов заглушек, которые можно загружать в Wiremock.

Таким образом, сочетание Cypress, Wiremock, ELK и небольшой самописной утилиты CLI по сборке логов позволяет удобно разрабатывать и поддерживать автотесты.

Вывод

Писать и поддерживать E2E тесты задача трудная, но отдачу от них трудно переоценить. При наличии покрытия тестами мы можем идти в релиз и не переживать, что придётся через пару часов в поте лица что-то чинить или откатывать. Поэтому, любая помощь, любая автоматизация в процессе поддержки E2E тестов окупается сполна. Wiremock здесь - один из элементов пазла. Он прекрасно подходит для тех случаев, когда нужно подменить внешние системы.