Platform V API Mock & Contract Testing: как мы создали enterprise-решение для интеграционного тестирования

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

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

Меня зовут Роман Гусев. Я директор по технологиям в СберТехе и вместе с командой развиваю Platform V Works — семейство инструментов для разработки программных продуктов и управления производственным процессом.

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

Какие сложности с интеграцией возникают у команд

СберТех — крупная компания, которая занимается enterprise-разработкой. И, естественно, наши команды в процессе работы сталкиваются с рядом интеграционных проблем. Мы проанализировали их и выделили три основные, которые, на мой взгляд, актуальны не только для наших команд:

1. Сложность проведения интеграционного тестирования на ранних этапах разработки

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

2. Недоступность интеграционных полигонов на этапе разработки и функционального тестирования

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

3. Стоимость позднего выявления дефекта

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

Все эти сложности увеличивали объем задач и замедляли нашу работу. Нужно было что-то с этим делать. 

Варианты оптимизации: shift-left и интеграционные эмуляции

Во-первых, мы решили сместить обнаружение интеграционных дефектов на более ранние этапы. Этот процесс называется 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. Мы продолжаем развивать его с помощью качественной обратной связи от наших пользователей, за которую очень благодарны.