С середины 2010-х в нашей жизни появились микросервисы, которые стали ответом на новые вызовы и новую скорость разработки. Однако теперь командам приходится затрачивать на интеграционные задачи больше ресурсов, ведь интеграции нужно разрабатывать и отлаживать как на сервисном, так и на микросервисном уровне.
Вместе с тем правильная организация интеграционного тестирования в рамках микросервисной парадигмы позволяет достичь высоких бизнес-преимуществ. Одно из основных — хорошие показатели масштабируемости.
Меня зовут Роман Гусев. Я директор по технологиям в СберТехе и вместе с командой развиваю Platform V Works — семейство инструментов для разработки программных продуктов и управления производственным процессом.
В этой статье поговорим о сложностях разработки, отладки и тестирования интеграций в enterprise-ландшафте и о том, можно ли создать вакцину от интеграционных проблем в подобной среде.
Какие сложности с интеграцией возникают у команд
СберТех — крупная компания, которая занимается enterprise-разработкой. И, естественно, наши команды в процессе работы сталкиваются с рядом интеграционных проблем. Мы проанализировали их и выделили три основные, которые, на мой взгляд, актуальны не только для наших команд:
1. Сложность проведения интеграционного тестирования на ранних этапах разработки
Часто путь от написания кода до выхода на интеграционный полигон занимает много времени. Этот процесс также включает в себя траты на запуск автотестов, Quality Gates, сборку и деплой.
2. Недоступность интеграционных полигонов на этапе разработки и функционального тестирования
Даже если вы вышли на интеграционный полигон, вы можете столкнуться с там, что смежная система будет недоступна. Приходится сообщать об этом коллегам и ждать, когда она заработает.
3. Стоимость позднего выявления дефекта
При позднем выявлении интеграционного дефекта команде придется вернуться к этапу разработки, а после перепройти тестирование и Quality Gates. Вне зависимости от степени автоматизации конвейера на это уйдет время и фокус команды.
Все эти сложности увеличивали объем задач и замедляли нашу работу. Нужно было что-то с этим делать.
Варианты оптимизации: shift-left и интеграционные эмуляции
Во-первых, мы решили сместить обнаружение интеграционных дефектов на более ранние этапы. Этот процесс называется shift-left тестирование (от англ. «смещение влево»).
При shift-left тестировании тестировщики и разработчики уже на начальных этапах более отчетливо понимают требования и архитектуру, могут проанализировать ситуацию и качественно выполнить поставленную задачу. Shift-left позволяет выявить и предотвратить появление интеграционных дефектов, а не исправлять их, когда продукт уже готов.
Во-вторых, решили развивать культуру использования интеграционных эмуляций, другими словами, заглушек API. Дело в том, что в интеграционном контуре не всегда есть необходимая версия смежной системы, с которой получится протестировать интеграцию: она может быть в процессе разработки, переустановки или же просто «упасть».
Заглушки как раз имитируют работу такой смежной системы:
1. Это позволит не ждать смежную систему на старте разработки и отладки.
2. QA-инженер сможет подготовить и пройти весь тестовый сценарий на стенде до стабилизации релиза смежной системы.
3. Команда сможет подготовить end-to-end сценарии с участием интеграций, например в selenium.
Мы начали внедрять культуру использования эмуляций. Одним из этапов стало проведение среди команд опроса, который выявил потребности:
· в переиспользовании эмуляций как на уровне команд, так и между командами;
· в публикации эталонных эмуляций еще не вышедшего API для потребителей / смежных команд;
· в использовании эмуляций API для разработки сценариев нагрузочного тестирования;
· и самое главное — в централизованной поддержке протоколов Kafka, HTTP, GRPC и MQ.
Мы стали искать подходящее решение. Но на рынке были только standalone-приложения или приложения, развернутые на сервере без интерфейса, каталога эмуляций и возможности обмениваться эмуляциями внутри команды. Такой вариант нам не подходил.
К тому же по требованиям безопасности данные могут храниться только в экосистеме банка. Выкладывать их в облачные сервисы за пределами группы компаний мы не можем.
Учитывая эти условия, мы создали собственный инструмент для работы с интеграционными эмуляциями —Platform V API Mock & Contract Testing.
Как работает решение
Если при интеграционном тестировании вы не используете эмуляции, ваш интеграционный полигон выглядит так:
То есть, если в процессе интеграционного тестирования что-то пойдет не так — например, смежная система разрабатывается, переустанавливается или недоступна по другим причинам — интеграции не получится.
А Platform V API Mock & Contract Testing помогает эмулировать работу смежной системы. Между ним и тестируемой системой появляется реальный транспорт — не эмуляция протокола, а настоящий «боевой» протокол. Например, HTTP, за которым стоят заглушки со сценариями поведения API. Вот как это выглядит:
В таких условиях API смежной системы доступны нам даже на самых ранних этапах тестирования. Мы сможем проверить интеграцию в любой момент, а это удобно.
Похожей функциональностью обладает сервис Mock Servers, который входит в состав инструмента Postman. Но Mock Servers работает в первую очередь с протоколом HТTP, а Platform V API Mock & Contract Testing на настоящий момент поддерживает HTTP, Kafka, MQ и может поставляться on-premise для клиентов вне группы компаний Сбер.
Platform V API Mock & Contract Testing также дает возможность коллаборативной работы в команде и в компании.Можно создать проектную область, добавить туда команду и совместно разрабатывать заглушки в веб-интерфейсе.
Обмениваться заглушками между командами можно через публичный каталог эмуляций. Если вы опубликуете эталонную заглушку, коллеги смогут воспользоваться ей для отладки своей системы.
Смежная система при обращении к ней может выдавать либо статический ответ, либо скрипт с обработкой входных данных. Его можно написать на языке программирования Groovy. Если задаться целью, то с его помощью можно написать даже такие ответы, что пользователь не отличит эмуляцию от реальной системы.
Вместо заключения
Каждый квартал мы измеряем показатель удовлетворенности команд работой инструмента. В 2022 году он составил в среднем 95%.
Мы зарегистрировали Platform V API Mock & Contract Testing в РРПО в прошлом году и сейчас активно занимаемся тиражом на внешнем рынке. Инструмент доступен в линейке продуктов СберТеха в рамках платформы Platform V. Мы продолжаем развивать его с помощью качественной обратной связи от наших пользователей, за которую очень благодарны.