Тестирование микросервисов - руководство для новичков

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

Прежде чем мы сможем увидеть, как тестировать микросервисы, нам сначала нужно понять, что это такое.

Что такое микросервисы?

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

• Работает в своем процессе.
• Взаимодействие с легковесным механизмом, часто с API ресурсов HTTP.
• Возможность независимого развертывания с помощью полностью автоматизированного оборудования.
• Использование разных языков программирования / технологий / БД.
• Использует разные технологии хранения данных.

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

Характеристики микросервисов:

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

Чем микросервисы отличаются от SOA

• Сервис-Ориентированная Архитектура (SOA): архитектурный шаблон в разработке компьютерного программного обеспечения, в котором компоненты приложения предоставляют услуги другим компонентам через протокол связи, обычно по сети.
• Микросервисы : Стиль архитектуры программного обеспечения, в котором сложные приложения состоят из небольших независимых процессов, взаимодействующих друг с другом с помощью независимых от языка API.

Пример:

Если бы Uber был построен с использованием SOA, их услуги могли бы быть:

• GetPaymentsAndDriverInformationAndMappingDataAPI
• AuthenticateUsersAndDriversAPI

Если бы Uber был построен с использованием микросервисов, их API-интерфейсы могли бы выглядеть примерно так:

• SubmitPaymentsService
• GetDriverInfoService
• GetMappingDataService
• AuthenticateUserService
• AuthenticateDriverService

Больше API, меньше обязанностей.

Как тестировать микросервисы

Единичные тесты

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

Стоит отметить, что одно только модульное тестирование не дает гарантий относительно поведения системы. Нам нужны другие виды тестирования микросервисов.

Компонентные тесты

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

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

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

Интеграционные тесты

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

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

Контрактные испытания

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

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

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

Сквозные тесты

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

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

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

Пример тестирования микросервисов

Возьмем микросервис К это зависит от двух других сервисов B & C . Вам необходимо создать изолированную среду, в которой состояние К , B а также C хорошо определен и может быть настроен повторно.

Например, состояние / хранение B а также C должны быть предварительно инициализированы. После этого вы просто запускаете набор тестов, проверяющих API микросервиса. К используя обычный набор инструментов тестирования REST / WebService, например МЫЛО или же Чакрам или простая альтернатива xUnit для вашего языка программирования.

Имитируйте любые одноранговые службы, от которых зависит API, используя restito. Другие альтернативы включают rest-driver, WireMock и Mochito.

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