Сервисы, в которых данные собираются и обрабатываются на основе других сервисов, очень чувствительны к интеграциям. Технические решения часто реализованы на брокерах, например, Kafka. У нашей команды была задача с финансовой отчетностью и десятками вариантов состояния документов.
В чем особенность: при ручной проверке тестировщику нужно самостоятельно формировать сообщения для Kafka, заполнять их корректными данными и согласовывать значения полей между сообщениями. Это особенно важно в сценариях, где один документ собирается из нескольких событий. Дополнительно, через один и тот же топик могут приходить сообщения, с индивидуальными правилами обработки, в зависимости от значений полей.
Чтобы регулярно проверять такие сценарии и не зависеть от ручной подготовки данных, есть вариант включить их в автотесты и добавить в регрессионные прогоны.
Немного о проекте
С точки зрения тестирования у проекта есть две ключевые особенности:
Бэкенд построен вокруг интеграций через Kafka.
Фронтенд содержит большое количество однотипных форм документов.
Формы в интерфейсе похожи по структуре, но различаются набором полей. Конкретный набор зависит от источника данных, типа и статуса документа, а также от роли пользователя. В системе несколько ролей, и у каждой — свой уровень доступа к данным и допустимым действиям.
Такая архитектура порождает два типа задач в тестировании:
На уровне интерфейса — нужно проверять множество вариантов отображения документов.
На уровне интеграций — проверять обработку входящих сообщений через Kafka и корректное создание документов на их основе.
Почему выбрали автотесты
Обе задачи плохо масштабируются при ручном тестировании. В интерфейсе количество комбинаций полей и ролей растет лавинообразно. В интеграциях — нужно готовить тестовые сообщения и контролировать прохождение данных через всю цепочку.
Поэтому мы выбрали подход с единым сценарием проверки и разными наборами входных данных. Сам тест остается неизменным — меняются только входные данные и ожидаемый результат. Это позволило покрыть разные варианты отображения документов без дублирования кода.
Для автоматизации мы использовали Cypress и расширили существующие сценарии проверками интеграций через Kafka.
Бизнес-задача: обработка разных типов сообщений в одном потоке данных
После того как покрыли проверки интерфейса, в регрессе осталась важная часть - создание документов через интеграции. Каждый документ формируется на огромном объеме динамически меняющихся данных, которые включают разную механику обработки.
Прием данных реализован через Kafka, в которую приходят сообщения, на основе которых создаются документы.
Сложность:
в одном топике приходят данные разных типов
тип будущего документа определяется значением поля типа документа
логика обработки зависит от дополнительных параметров сообщения.
В рамках одного сценария система должна:
отфильтровать часть сообщений
определить тип создаваемого документа
разобрать поля по разным правилам в зависимости от типа
собрать один документ из нескольких сообщений с одинаковыми идентификаторами
Каждое сообщение добавляет строку расхода, а ожидаемое количество строк также приходит в данных. Ошибка на любом из этих этапов критична.
Решение
Задачу не стали решать отдельно от существующих автотестов. Вместо этого расширили уже готовые сценарии проверки документов.
В тесты добавили шаг отправки сообщений в Kafka. Для этого использовали API тестового контура и формировали сообщения с нужными параметрами, включая DocType, идентификаторы и данные строк расходов.
После отправки данных тест выполняет те же действия, что и раньше:
авторизация под нужной ролью,
поиск документа по номеру,
проверка полей, строк учета и статуса,
Таким образом, один сценарий покрывает весь путь от входящего сообщения до отображения документа в интерфейсе.
С какими проблемами мы столкнулись
Основная сложность - асинхронная обработка сообщений. Документ не появляется сразу после отправки данных, и тест может не найти его в момент проверки.
Чтобы избежать нестабильности, добавили паузу после отправки сообщений и повторные попытки проверки. Тест несколько раз ищет документ по номеру и продолжает выполнение, как только он появляется.
Вторая сложность связана с поиском документа. При создании через интерфейс документ сразу открыт на экране. При создании через интеграцию он появляется в системе после обработки сообщений и не открывается автоматически. Поэтому перед проверкой его нужно сначала найти по номеру.
Результат
После внедрения подхода интеграционные сценарии стали частью регресса и выполняются вместе с остальными тестами. Это дало не только удобство, но и заметный эффект в процессе тестирования.
Во-первых, сократилось время проверки интеграций. Ручная smoke-проверка сценариев с несколькими типами документов сократилась в 5 раз.
Во-вторых, интеграционные проверки стали регулярными. Ранее, если изменения не затрагивали обработку сообщений, эти сценарии могли пропускаться, чтобы сократить время time to market. После автоматизации их стали выполнять в каждом релизе.
Это напрямую повлияло на уверенность в системе. Данные, которые поступают в Kafka, формируются пользователями в других системах и могут содержать ошибки. При сбоях было сложно понять, проблема в данных или в обработке. Регулярные проверки позволили быстрее локализовать причину и сократить время разбора инцидентов.
Кроме того, автотесты помогли обнаружить ошибки, которые не были связаны напрямую с текущими задачами.
Интеграционные сценарии удалось включить в регрессионные проверки без усложнения существующих тестов.
Проверки стали регулярными и не зависят от ручной подготовки данных.