Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей вы столкнетесь с выдуманным, но реалистичным сценарием использования контрактного тестирования с Pact и Pactflow.

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

Этот распределенный подход к разработке ПО имеет ряд существенных преимуществ, особенно в плане гибкости и масштабируемости:

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

Помимо этих, есть и другие плюсы. Однако этот подход к разработке несет и проблемы, особенно в интеграции и end-to-end тестировании. Чтобы пристальнее взглянуть на эти проблемы и пути их решения, возьмем для примера приложение, состоящие из нескольких неплотно связанных компонентов.

Приложение

Эта и последующие статьи в серии будут вертеться вокруг онлайн-магазина, продающего и доставляющего бутерброды в США. Приложение спроектировано и разработано на основе микросервисной архитектуры. Изначально мы сконцентрируемся на трех компонентах – частях этой архитектуры.

Пользовательский API (потребитель)

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

Пользовательский API разработан и запущен, в соответствии с модой на DevOps, командой "Пользователь", которая работает в головном офисе нашей компании по доставке бутербродов.

API заказов (потребитель)

Если наш магазин не сможет принимать и обрабатывать заказы, мы вскоре разоримся. Чтобы отслеживать заказы и все сопутствующие данные, мы используем Order API. Этот API тоже потребитель данных Address API, и используется для отслеживания адресов конкретных заказов. Данные о заказе также выдаются в веб онлайн-магазина и мобильное приложение, которыми люди пользуются для заказа бутербродов.

Order API разработан и запущен командой Order. Как и команда Customer, они работают в головном офисе нашей компании.

API адресов (провайдер)

Как уже упоминалось, и Customer, и Order API потребляют данные о платежах и адресах доставки соответственно. Эти данные предоставляются Address API, предоставляющим следующие операции создания, чтения, обновления и удаления (CRUD) для адресов:

GET /address/{id}
Когда адрес с ID {id} найден в базе адресов, эта операция возвращает примерно следующее:
{
"id": "87256abc-f6b3-4e91-9f60-3ca3f54863d5",
"addressType": "billing",
"street": "Main Street",
"number": 123,
"city": "Nothingville",
"zipCode": 54321,
"state": "Tennessee",
"country": "United States"
}
POST /address

Эта операция создает новый адрес в базе данных. Она принимает примерно такой запрос (все поля обязательные):

{
"addressType": "billing",
"street": "Main Street",
"number": 123,
"city": "Nothingville",
"zipCode": 54321,
"state": "Tennessee",
"country": "United States"
}
PUT /address/{id}

Эта операция обновляет существующий адрес в базе данных. Запрос аналогичен запросу для POST.

DELETE /address/{id}

И, наконец, API также дает возможность удалить из базы существующий адрес.

Компания

Address API разработан и запущен командой Address. В отличие от команд Customer и Order, эта команда работает в подразделении на другом конце страны.

Ниже – графическое представление взаимоотношений между вышеописанными компонентами:

Процесс тестирования

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

Интеграция и end-to-end тестирование, однако – дело другое. Команды страдают от ряда проблем, пытаясь создавать и запускать эти тесты:

• Для проведения end-to-end тестов нужно сложное тест-окружение, состоящие из всех задействованных компонентов. Оно должно предоставляться каждый раз, когда нужно проводить эти тесты.
• Разные компоненты разрабатываются разными командами, и у каждой – свое расписание, свой бэклог. Это значит, что командам часто приходится ждать друг друга, чтобы провести интеграционное тестирование.
• Не всегда понятно, кто отвечает за интеграцию, потому что масштаб этих тестов пересекает границы разных команд.
• Так как команда Address находится на другом конце страны, есть коммуникационный барьер – нельзя просто взять и подсесть за их стол. Большая часть коммуникации ведется через почту, Slack и Jira, и в ходе этого теряется масса информации.

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

Мы подробно разберем, как команды справляются с этими проблемами, во второй статьей серии.

Обсудить в форуме