Повышаем надежность интеграций с RabbitMQ. Интеграционные и контрактные тесты в несколько кликов

Меня зовут Кузин Роман. Я корпоративный архитектор в Группе компаний «Пик», где сейчас занимаюсь формированием и проектированием бизнес-технической архитектуры. Данная статья основана на моем опыте в «МТС Диджитал», где я работал системным архитектором и у меня был широкий круг задач. Там я занимался проектированием, автоматизацией, Devops-ом, безопасностью, мониторингом и т.д., начиная от требований, заканчивая релизом на прод бек-офисных систем в экосистеме МТС.

Также хочу упомянуть, что я разработал программу курса «Архитектор 1С», руководил курсом и преподавал более года.

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

Моя статья опирается на несколько ключевых тезисов:

• Данные – главный актив компании. Потеря данных или их несоответствие ведет к ошибкам и сбоям.

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

• Решение этой проблемы – интеграционные и контрактные тесты – это основа стабильности и качества данных в интеграциях.

 

Контур 1С в MTS Digital и используемые технологии

 

В контуре 1С в «МТС Диджитал» работает более пяти конфигураций – как типовые, так и кастомные, разработанные самостоятельно.

Основным транспортом для интеграции с другими системами выступает RabbitMQ (RMQ). Каждая конфигурация включает встроенную библиотеку для взаимодействия с RabbitMQ,

Потребителями данных из 1С являются более 70 продуктов, а количество типов сущностей, которыми системы обмениваются, превышает 100.

Инфраструктура поддерживает современные практики разработки: используется CI/CD, автоматизированное тестирование, мониторинг, гибкие методики разработки. Важно отметить, что весь код хранится в Git.

Для реализации CI/CD задействован Jenkins, а тестирование выполняется в средах Vanessa-ADD и Vanessa Automation.

 

Вводная: что такое интеграционные и контрактные тесты

 

Зачем вообще нужны интеграционные и контрактные тесты, и что они из себя представляют?

Интеграционные тесты – это проверки, которые смотрят, как разные части приложения работают вместе. Например, у нас есть система A и система B – не важно, написаны ли они на 1С, Python, Go или другом стеке. Нам нужно убедиться, что при формировании и отправке сущности из системы A в систему B все работает корректно.

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

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

 

Причины перехода к контрактным тестам: обновление системы УХ

 

Была одна уникальная система – назовем ее условно УХ – которая, как нам пообещали, никогда не будет обновляться, она будет существовать вечно. И все развитие системы шло с учетом этого.

Но, как это часто бывает, приходит бизнес-задача, в которой требуется обновление системы. Мы начали обсуждать, как дешевле всего реализовать задачу. В итоге пришли к выводу, что единственным экономически оправданным способом является обновление самой системы УХ. Других вариантов просто не было.

Важно понимать, что УХ – это MDM-система по ряду ключевых сущностей. То есть именно там рождаются данные, которые затем распространяются в десятки других систем. Поэтому, прежде чем запускать обновление, мы решили проверить, что изменится в интеграциях и с какими проблемами мы можем столкнуться.

И увидели, что:

• Изменились поля и атрибуты сообщений,

• Всего из УХ генерируется 30-40 видов сообщений в формате JSON,

• В некоторых сообщениях более 30 атрибутов и вложенных сущностей (массив структур).

И мы решили понять, а сколько полей изменилось в рамках этих сущностей. То есть была УХ – мы ее обновили, а что изменилось?

Конечно, при обновлении релиза УХ на 10+ версий поля меняются, документы трансформируются, типы данных корректируются. Но в чем же проблема? Невозможно быстро и эффективно сравнить данные в JSON и найти ошибки. Выверять между 30-40 сущностями действительно проблематично.

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

Что можно было сделать? Можно было выгрузить данные в Git: старую версию, новую, и посмотреть diff. Да, это логичный подход. Но и он все равно требует ручной проверки.

Мы пошли дальше: я написал парсер JSON – инструмент, который сравнивает два JSON-сообщения. Он преобразует каждый JSON в структуру (массив структур), рекурсивно проходит по всем полям и проверяет их соответствие.

Именно на основе этого парсера и будут построены все интеграционные и контрактные тесты, про которые я расскажу в этой статье.

 

Проблемы, выявленные при обновлении системы

 

Какие еще проблемы мы выявили в ходе обновления?

 

 

• Изменения в методах: обнаружили, что триггеры для генерации сообщений изменились. Раньше сообщение формировалось и отправлялось, например, при записи справочника или проведении документа. Либо есть волшебная кнопка «отправить», после нажатия которой отправлялось сообщение,

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

• Библиотека не стандартизирована и имеет разные версии в каждой конфигурации 1С. Новые фичи невозможно быстро интегрировать в контур 1С. Мы хотим допилить какую-то часть библиотеки, но не можем встроить новую полезную фичу, чтобы быстрее и проще работать с библиотекой, потому что они все в полном рассинхроне.

В итоге мы приняли решение, что необходимо адаптировать и стабилизировать подсистему для интеграции с RabbitMQ.

 

Адаптация и стабилизация библиотеки RabbitMQ

 

С какими проблемами мы столкнулись при адаптации и стабилизации библиотеки RabbitMQ для запуска тестов?

Первая проблема – Библиотека RMQ, которая использовалась, не была на «замке» и не распространялась как поставка во все 1С. За 3 года контроль осуществлялся с переменным успехом. К чему это привело?

• Неизменны только часть «типовых» методов, остальные переписаны,

• Разные методы для вызова сообщений, то есть часть сообщений генерится через общий модуль, часть через обработку и так далее,

• В одной из конфигураций 1С библиотека переписана более чем на 80%, т.к. использует методологию отложенной сериализации сообщений, где сообщение сначала регистрируется, а затем формируется и отправляется.

 

 

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

 

 

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

И код, который относится к бизнес-логике и не относится к подписке. То есть какой-то договор согласован, передается ссылка, и здесь этого кода быть не должно.

Каков наш путь?

• Выравниваем код в обработчиках и стандартизируем основные функции в конфигурации.

• Переносим код с бизнес-логикой в переопределяемые модули.

• Создаем единое окно/процедуру для вызова генерации сообщения на основе ссылки, для которой оно создается. Ссылкой-источником может быть любой объект – справочник, документ, регистр и так далее.

• Унифицируем все разрозненные библиотеки в конфигурациях.

 

 

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

Напомню, у нас более пяти конфигураций и около 10–15 баз.

 

 

Здесь есть список всех измененных модулей, который составлен с использованием git blame. Указано, сколько модулей было переписано, сколько добавлено во время стандартизации и адаптации библиотеки.

 

Подготовка данных для контрактных тестов

 

Мы подошли к ключевой части. Еще раз вспомним, что такое контрактные тесты, и подробно разберем, как устроен процесс работы с ними. Опишем «базу» построения теста и подготовки данных для него, с которых все начинается, а также введем немного теории.

Как работают любые тесты?

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

• Чтобы проверить эталонные данные, их необходимо откуда-то взять и сравнить с тестовыми данными.

Опишем процесс формирования тестовых и эталонных данных, откуда мы их берем.

 

 

У нас есть исходящее сообщение, в котором хранится наше сообщение в формате JSON. Мы создаем новый реквизит «СсылкаНаИсточник» в объекте «Исходящее сообщение» (на рисунке).

При генерации сообщения «СсылкаНаИсточник» будет храниться в справочнике, вместе с эталонными данными. То есть эталонные данные – это JSON, который мы сейчас храним.

Зная ссылку на источник и тип пакета (например, contract – для договора или person – для физического лица), мы можем в любой момент повторно сформировать это сообщение. Это ключевой момент: зная исходные данные, мы можем перегенерировать JSON сколько угодно раз.

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

 

Логика и реализация контрактного теста

 

В чем логика контрактного теста?

• Храним старый JSON и исходящее сообщение в макете обработки. Это может быть не макет обработки, в Vanessa-ADD мы можем хранить данные где угодно – это может быть файл на диске, другая база или другие способы.

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

• Превращаем поля старого и нового JSON-объектов в массив структур и сравниваем их.

Что может поменяться и что нужно проверить?

• Может добавиться атрибут внутри JSON-сообщения, и нам нужно понять, корректно ли он добавился и нужен ли он.

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

• Может измениться значение поля внутри JSON-сообщения.

• Сообщение вообще может не сгенерироваться: мы пытаемся сформировать контрактный тест, а у нас нет сообщения.

Какие этапы генерации данных для формирования контрактного теста мы пройдем?

• В Vanessa-ADD формируем табличный документ через обработку «Сериализатор MXL». Vanessa-ADD прекрасно работает с макетами, поэтому мы будем использовать этот механизм.

• Отбираемся по справочнику «Исходящие сообщения».

 

 

• Вставляем данные табличного документа в макет, который мы сгенерировали и запускаем тесты.

• И часть из них периодически падает на разных базах.

Мы написали контрактные тесты, сформировали исходящее сообщение, у нас есть эталонные и тестовые данные, но все равно все постоянно падает на разных пакетах. Почему?

 

 

Проблема в том, как устроен процесс. Мы копируем базу с прода через Jenkins. И пока идет этот процесс, данные, находящиеся в макете во время сериализации, могут изменяться. Например, бухгалтер заходит в справочник контрагентов, меняет ИНН или наименование. Контрактный тест отрабатывает и фиксирует расхождение. Технически он прав: поля изменились. Но суть в том, что это уже нормальный бизнес-кейс.

Что мы будем с этим делать?

• Теперь при генерации теста начнем добавлять все связанные объекты из сообщения в макет для генерации данных, то есть будем, по сути, эмулировать создание объектов.

• При генерации макетов с данными сделаем подмену guid, чтобы все уникальные идентификаторы в макете при создании объектов были новыми. Таким образом тест при запуске каждый раз будет генерировать новые объекты, будет работать с новыми guid, и тест будет всегда независимым – он не будет зависеть от объектов, которые хранятся в БД, и работать с ними.

Какой тюнинг Vanessa мы сделали? Добавили все связанные объекты из сообщения и ускорили поиск этих объектов для наполнения макета с данными, чтобы быстрее их находить.

В итоге тесты становятся «зелеными», потому что мы скопировали данные, создали абсолютно новые данные с новыми guid.

 

Архитектура интеграционных тестов и проверка библиотеки

 

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

Хочу напомнить: мы не только стандартизируем, но и наполняем разными фичами нашу библиотеку в момент перехода на новый релиз УХ.

 

 

Давайте разберем архитектуру библиотеки и что делает Vanessa-ADD на каждом из этапов.

1. Vanessa-ADD делает запрос на генерацию сообщения.

2. 1С формирует ключ маршрутизации, с помощью которого брокер в различные очереди маршрутизирует данные.

3. Дальше выполняются проверки и стандартные функции.

4. Затем формируется хэш сообщения.

Что такое хэш сообщения? Представьте, что у вас есть объект – например, физическое лицо. Как кадровик, я могу зайти в карточку и восемь раз подряд нажать «Записать», после чего у меня сформируется восемь сообщений.

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

Vanessa-ADD проверяет каждый из этих этапов: она проверяет, что сообщение не сгенерировано или сгенерировано по хэшу, создает и проверяет очереди, проверяет отправлено ли сообщение из 1С. От начала генерации сообщения, проверки контракта сообщения и до получения обработки сообщения – Vanessa-ADD все проверяет в интеграционных тестах.

 

Процесс создания теста по шагам

 

Теперь пройдем этап построения теста от начала до конца и заглянем «под капот».

 

 

Существует единая точка входа для запуска теста, в которой:

• фиксируется дата создания,

• подготавливаются тестовые данные, которые лежат в макете,

• запускаются внутренние проверки.

Что происходит дальше?

В методе «ЗаполнитьНаборТестов» мы определяем виды тестов, которые будем запускать. Полное покрытие интеграционных тестов от формирования сообщения до его получения и обработки в цикле обрабатывается по каждому пакету.

 

 

В методе «ОпределитьПакеты» лежит вот такая структура:

 

 

В ней мы обозначаем, какой пакет мы добавляем в тестирование. Эти строчки являются своеобразным триггером: мы добавляем строку – тест включается, закомментировали строку, удалили ее по пакету – тест исключился из проверки.

Далее создаем необходимые элементы для работы теста, такие как серверы очередей, подписчики для подключения и узлы, то есть системные справочники и объекты, которые нужны для того, чтобы тест запустился и Rabbit работал вместе с 1С. Для этого мы также используем заранее подготовленный макет:

 

 

Так хранится справочник «Исходящие сообщения» в макете, а также вложенные служебные сущности:

 

 

Здесь мы можем видеть все связанные объекты, которые выгружаем. Есть «Исходящее сообщение» (физическое лицо) и все связанные объекты, регистры, справочники и все остальное.

Когда все готово, мы можем перейти к пошаговому процессу создания теста.

 

Реальный пример: создание теста для пакета employee

 

Как создать новый контрактный интеграционный тест буквально в несколько кликов? Давайте разберем этот процесс на конкретном примере:

• Необходимо создать новый интеграционный и контрактный тест по пакету employee.

• Пакет генерируется в ЗУП и формируется при проведении любого кадрового документа. Например, это документ «Кадровый перевод».

• Проведем документ «Кадровый перевод».

 

 

Проводим документ «Кадровый перевод». Находим «Исходящее сообщение» с верной ссылкой на источник. Находим в системе соответствующее исходящее сообщение по корректной ссылке. Идентификатор 9274705.

 

 

Отбираемся по исходящему сообщению в обработке «Генерация макета».

 

 

После этого отбираемся по ссылке на источник, который участвует в сообщении, чтобы сгенерировать сообщение.

 

 

Затем отбираем данные, которые участвуют в сообщении, чтобы сгенерировать их.

 

 

После этого у нас формируется макет (слева на изображении). Затем добавляем наш макет в обработку для запуска теста. Называем его employee.

 

 

После этого с триггером, про который я говорил – ДобавитьИсключаемыеПоля – запускаем наш тест в Vanessa-ADD:

 

 

Тест выполнен успешно. Остальные тесты (которые проверяют интеграцию) добавились в тест по умолчанию.

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

 

Автоматизация тестирования через Jenkins и анализ результатов

 

Давайте посмотрим, как это все работает с Jenkins, как происходит автоматизация тестирования в Jenkins и в какой момент происходит написание контрактного и интеграционного теста.

 

 

Представим это в формате: слева – событие, справа – действие.

Сначала создается новое JSON-сообщение. Мы пишем новый тест.

Если происходит изменение в существующем JSON-сообщении – например, добавляется новый атрибут или меняется структура пакета, то мы либо создаем новый тест, либо адаптируем уже существующий.

Когда тесты готовы, мы запускаем их вручную на тестовой среде. Если все проходит успешно – тесты «зеленые».

Тест проверены – создаем pull-request задачи и размещаем в Gitlab. Как я уже говорил, мы используем Git, а значит по ветке и задаче можно положить тест, который мы используем.

Далее наступает время регламентного запуска. С помощью Jenkins мы разворачиваем контур тестирования, снимаем его с прода, обезличиваем, и запускаются вообще все тесты, которые у нас есть – интеграционные, контрактные, сценарные – без исключения.

Все результаты тестирования собираются и анализируются в AllureTestOps. Это расширенная платформа на базе Allure, где мы можем проверить, как работают тесты и какие у нас результаты.

 

 

Так выглядит AllureTestOps. Здесь мы видим, что упал конкретный контрактный тест по конкретному договору, видим поля, которые изменились – это ID_APPLICANT.

 

Рефлексия: проблемы, вызовы и выводы

 

Рассказываю, какие у нас были проблемы, с какими вызовами мы столкнулись и какие выводы можно сделать.

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

• Стандартизация библиотеки RMQ в рамках огромного зоопарка 1С-систем и различий в них. Это действительно сложно, но тесты нам сильно помогли, потому что если бы мы каждый раз, когда добавляли новую фичу, тестировали каждый пакет, который рождается в рамках конкретной конфигурации, то можно было бы сойти с ума.

• Сложность написания корректных и стабильных интеграционных тестов, покрывающих всю функциональность библиотеки. Нужно потратить очень много времени, чтобы написать интеграционные тесты, полностью покрывающие всю функциональность библиотеки от генерации до получения и обработки.

• Проблема в поиске связанных сущностей, когда мы не можем найти сущность, которая используется в пакете. Например, в пакете employee есть ссылка, которая лежит в регистре, где нет явной передачи ссылки на регистр – это какой-то guid. То есть система не может понять, откуда ей взять данные, связанные сущности не сериализуются и мы не можем добавить их в макет. Возникает проблема контрактного теста, и нужно искать эти сущности, которые надо добавить в макет.

 

Заключение

 

Подведу итоги нашего подхода к написанию тестов с RabbitMQ.

• Качество и стабильность. Интеграционные и контрактные тесты стали основой для надежного обмена данными между более чем 70 системами. Качество релизов улучшилось, а количество ошибок уменьшилось,

• Адаптация и автоматизация. Мы успешно адаптировали библиотеку RMQ для 1С и оптимизировали процесс написания тестов, что значительно упростило их запуск.

• Инструменты и результаты. Использование Jenkins и AllureTestOps позволило нам эффективно отслеживать результаты тестирования и выявлять проблемы на ранних этапах.

• Преодоление вызовов. Мы столкнулись с рядом трудностей, но каждый вызов стал возможностью для улучшения нашего подхода.

 

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.