Сервисы, в которых данные собираются и обрабатываются на основе других сервисов, очень чувствительны к интеграциям. Технические решения часто реализованы на брокерах, например, Kafka. У нашей команды была задача с финансовой отчетностью и десятками вариантов состояния документов.

В чем особенность: при ручной проверке тестировщику нужно самостоятельно формировать сообщения для Kafka, заполнять их корректными данными и согласовывать значения полей между сообщениями. Это особенно важно в сценариях, где один документ собирается из нескольких событий. Дополнительно, через один и тот же топик могут приходить сообщения, с индивидуальными правилами обработки, в зависимости от значений полей.

Чтобы регулярно проверять такие сценарии и не зависеть от ручной подготовки данных, есть вариант включить их в автотесты и добавить в регрессионные прогоны.

Немного о проекте

С точки зрения тестирования у проекта есть две ключевые особенности:

• Бэкенд построен вокруг интеграций через Kafka.

• Фронтенд содержит большое количество однотипных форм документов.

Формы в интерфейсе похожи по структуре, но различаются набором полей. Конкретный набор зависит от источника данных, типа и статуса документа, а также от роли пользователя. В системе несколько ролей, и у каждой — свой уровень доступа к данным и допустимым действиям.

Такая архитектура порождает два типа задач в тестировании:

1. На уровне интерфейса — нужно проверять множество вариантов отображения документов.

2. На уровне интеграций — проверять обработку входящих сообщений через Kafka и корректное создание документов на их основе.

Почему выбрали автотесты

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

Поэтому мы выбрали подход с единым сценарием проверки и разными наборами входных данных. Сам тест остается неизменным — меняются только входные данные и ожидаемый результат. Это позволило покрыть разные варианты отображения документов без дублирования кода.

Для автоматизации мы использовали Cypress и расширили существующие сценарии проверками интеграций через Kafka.

 Бизнес-задача: обработка разных типов сообщений в одном потоке данных

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

Прием данных реализован через Kafka, в которую приходят сообщения, на основе которых создаются документы.

Сложность:

• в одном топике приходят данные разных типов 

• тип будущего документа определяется значением поля типа документа 

• логика обработки зависит от дополнительных параметров сообщения. 

В рамках одного сценария система должна:

• отфильтровать часть сообщений 

• определить тип создаваемого документа 

• разобрать поля по разным правилам в зависимости от типа 

• собрать один документ из нескольких сообщений с одинаковыми идентификаторами 

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

Решение

Задачу не стали решать отдельно от существующих автотестов. Вместо этого расширили уже готовые сценарии проверки документов.

В тесты добавили шаг отправки сообщений в Kafka. Для этого использовали API тестового контура и формировали сообщения с нужными параметрами, включая DocType, идентификаторы и данные строк расходов.

После отправки данных тест выполняет те же действия, что и раньше:

• авторизация под нужной ролью,

• поиск документа по номеру,

• проверка полей, строк учета и статуса,

Таким образом, один сценарий покрывает весь путь от входящего сообщения до отображения документа в интерфейсе.

С какими проблемами мы столкнулись

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

Чтобы избежать нестабильности, добавили паузу после отправки сообщений и повторные попытки проверки. Тест несколько раз ищет документ по номеру и продолжает выполнение, как только он появляется.

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

Результат

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

Во-первых, сократилось время проверки интеграций. Ручная smoke-проверка сценариев с несколькими типами документов сократилась в 5 раз.

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

Это напрямую повлияло на уверенность в системе. Данные, которые поступают в Kafka, формируются пользователями в других системах и могут содержать ошибки. При сбоях было сложно понять, проблема в данных или в обработке. Регулярные проверки позволили быстрее локализовать причину и сократить время разбора инцидентов.

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

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

Проверки стали регулярными и не зависят от ручной подготовки данных.