ГЛОССАРИЙ 3
ВВЕДЕНИЕ 4
ГЛАВА 1. ОБЗОР СУЩЕСТВУЮЩИХ ПОДХОДОВ К НТТР-МОКАМ 7
1.1 Изоляция модулей при тестировании 7
1.2 Предметная область 9
1.3. Требования к системе 9
1.4. Существующие решения 13
1.4.1. Mockoon 14
1.4.2 Mountebank 16
ГЛАВА 2. ПРОЕКТИРОВАНИЕ СИСТЕМЫ 19
2.1 Сущности предметной области 19
2.2 Сценарии использования 24
2.3 Диаграммы компонентов 25
2.4 ER диаграммы 27
ГЛАВА 3. РЕАЛИЗАЦИЯ 29
3.1 Выбор платформы и технологий 29
3.2 Проектирование модели конфигурации, доступной пользователю для
редактирования 31
3.3 Реализация сущностей предметной области - пространство имен Core 33
3.3.1 Проектирование интерфейсов для всех моделей 33
3.3.2 Классы сущностей предметной области 35
3.3.3 Обновление конфигурации и инфраструктура для нее. 38
ЗАКЛЮЧЕНИЕ 41
СПИСОК ЛИТЕРАТУРЫ 43
Примерно с середины 2010-х годов при проектировании сложных вычислительных систем, требующих высокой степени отказоустойчивости и быстрого масштабирования, разработчики все чаще обращаются к микросервисной архитектуре. [5] Микросервисный подход подразумевает сетевое взаимодействия сервисов.[11]
Стандартом индустрии также стала практика написания модульных и интеграционных автоматических тестов.[10] Написание автоматических тестов позволяет оперативно отследить, как изменения нарушают логику работы программы. Особенно полезны интеграционные тесты - они позволяют удостовериться, что внесение изменения в отдельный модуль программы не нарушает правильной работы всей программной системы.[1]
Особенностью процесса разработки в рамках микросервисной архитектуры является высокая степень независимости разработки конкретного сервиса от остальных сервисов системы.[13] Проектирование и реализация сервисов может вестись силами различных команд и релизные циклы сервисов системы могут не совпадать. При этом сохраняются зависимости между сервисами системы, поскольку они совершают сетевые вызовы к другим сервисам и обладают поведением, которое зависит от результатов таких вызовов. Когда разработка сервиса доходит до этапа написания автоматических тестов, особенно интеграционных тестов, возникает необходимость тестирования законченного комплексного сценария, требующего взаимодействия с другим сервисом, чтобы убедиться что разработанный сервис корректно работает со сценарием. При этом нужно исключить необходимость реального взаимодействия с сервисом-зависимостью и развертывания зависимости и исполнение кода зависимости. [9] Есть несколько причин, почему исполнение тестируемого сценария, среди которых одними из основных являются:
1) Независимость цикла разработки сервиса-зависимости от разрабатываемого сервиса. Сервис-зависимость может быть еще только на этапе проектирования и выбора варианта конкретной реализации. В таком случае, может быть только обозначен интерфейс и правила взаимодействия с ним.
2) Избежание написания “хрупких” тестов. Тест становится “хрупким”, когда незначительное или непрямое изменение тестируемой системы, не отражающее изменение поведения или нарушение контракта системы, приводит к провалу теста. Так как зависимости могут определять результат поведения сервиса, любое некорректное поведение зависимости может привести к провалу теста, даже если сам сервис работает корректно и его код не содержит ошибок. [19]
3) Избежание дополнительных затрат на конфигурирование из-за транзитивных зависимостей. Внесение реального сервиса-зависимости под тест предполагает дополнительные затраты на конфигурирование и поддержку целостности дерева всех зависимостей.
Обычной практикой при модульном тестировании является использование моков - конфигурируемых “заглушек”, которые имитируют ожидаемое поведение зависимостей в рамках одного сценария. Моки не имеют зависимостей и позволяют эффективно настроить ожидаемое от них поведение. Подобный принцип можно применить и в отношении микросервисов. Конфигурация заглушек для сетевых вызовов к сервисам-зависимостям позволит изолировать микросервис и тестировать только непосредственно работу разрабатываемого сервиса. [18] Стандартизированного подхода и
инструмента для конфигурации моков для сетевых ресурсов, которыми являются микросервисы, на текущий момент не существует.
Объектом работы является практика интеграционного тестирования микросервисов.
Предметом работы является изоляция таких микросервисов от их зависимостей и их поведения. Преимущественно рассматривается изоляция от зависимостей на сетевом уровне, т.к. такой уровень изоляции в наибольшей степени соответствует принципам микросервисного подхода о независимости сервисов, соответственно позволяет создавать наиболее полные интеграционные тесты.
Целью работы является создание инструмента для конфигурирования ответов-заглушек для запросов к другим ресурсам по сети.
Задачи
В рамках данной работы необходимо решить следующие задачи :
1. Рассмотреть предметную область и провести анализ существующих практик интеграционного тестирования микросервисных систем для выявления требований к инструменту.
2. Спроектировать пользовательский API инструмента, сущности предметной области и сценарии использования.
3. Реализовать инструмент для конфигурирования ответов-заглушек для запросов к другим ресурсам по сети.
В данной работе рассмотрена проблема имитации поведения зависимостей при интеграционном тестирования микросервисов. Целью работы была разработка инструмента, позволяющего разработчикам имитировать ответы от сервисов-зависимостей при интеграционном тестировании микросервисов.
В ходе работы были выполнены обзор существующих практик интеграционного тестирования и выявлена предметная область решения: взаимодействие по протоколу HTTP, настройки для проверок входящих запросов и шаблоны ответов - конфигурируемое поведение заглушек. Также выявлены основные требования к инструменту для создания заглушек для зависимостей-микросервисов:
• Имитировать поведение закрываемых сервисов согласно
пользовательским конфигурациям.
• Позволить пользователю разделять закрываемые сервисы по ресурсам
• Позволить пользователю сконфигурировать правила, включающие в себя проверку запроса и шаблон ответа.
• Поддержать обновление конфигураций без остановки приложения и сохранение конфигураций в централизованном хранилище.
В работе рассмотрены существующие инструменты для создания сетевых заглушек, проведен анализ их достоинств и недостатков. Было установлено, что существующие решения не удовлетворяют выявленным требованиям в полной мере.
Был спроектирован механизм изоляции зависимых микросервисов для интеграционного тестирования: зафиксированы принципы работы и отношения компонент, выделены сущности предметной области.
