После того как я попробовал изучить Гексагональную Архитектуру, я пришел к пониманию, что идея порта и адаптера – это всего лишь внедрение зависимостей, основанное на внедрении интерфейсов, и мне просто интересно, как эта концепция поможет в тестировании, о котором упоминают большинство видео и сайтов.
Если я не использую порт и адаптер (внедрение интерфейсов), я обычно использую базовое внедрение зависимостей через конструктор, и когда я хочу замокировать что-то, я могу сделать это сразу же с помощью mock-фрейма.
Таким образом, разница между использованием порта и адаптера и отсутствием его заключается лишь в том, что я замокирую интерфейс или конкретный объект, что на самом деле ни на что не влияет.
Пожалуйста, дайте знать, если я что-то упустил.
Спасибо.
Больше информации о внедрении зависимостей и Гексагональной Архитектуре.
Ответ
Hexagonal Architecture, или архитектура в форме шестиугольника, действительно предоставляет некоторые преимущества, когда дело доходит до тестирования, и это различие важнее, чем просто возможность мокирования объектов. Давайте разберемся, как именно эта архитектура способствует более качественному тестированию.
Понимание Hexagonal Architecture
В Hexagonal Architecture вы разделяете бизнес-логику вашего приложения от внешних систем (таких как базы данных, веб-сервисы и пользовательские интерфейсы) с помощью портов и адаптеров. Порты определяют интерфейсы, через которые ваша бизнес-логика взаимодействует с внешними системами, а адаптеры реализуют эти интерфейсы для конкретных технологий.
Преимущества для тестирования
-
Отделение бизнес-логики от внешних зависимостей: Поскольку бизнес-логика изолирована от внешних систем, вы можете тестировать её в полном объёме, не задействуя реальные зависимости. Это позволяет создавать юнит-тесты, которые проверяют только бизнес-логику, что делает их более надежными и быстрыми.
-
Легкость замены зависимостей: В Hexagonal Architecture обычно используется интерфейс для описания зависимости (порт). Например, если у вас есть зависимость от службы уведомлений, вы можете создать интерфейс
NotificationService, и в вашем приложении вы будете использовать этот интерфейс. Во время тестирования вы можете легко заменить реальную реализацию мок-объектом, который реализует тот же интерфейс. Это позволяет вам точно контролировать поведение внешних систем во время теста. -
Тестирование различных сценариев: Вам не нужно иметь доступ ко всем внешним системам для тестирования бизнес-логики. Эти системы могут быть сложными и медленными, и вы можете иметь тесты, которые обращаются к этим системам, но благодаря адаптерам вы также можете использовать фиктивные или поддерживаемые реализации, чтобы протестировать различные сценарии.
-
Упрощение интеграционного тестирования: Порты и адаптеры помогают создать четко определенные области, где вы можете проводить интеграционные тесты. Мокируя один адаптер (например, базу данных или внешнюю службу), вы можете протестировать, как ваша бизнес-логика взаимодействует с этими системами, не имея необходимости использовать реальные внешние ресурсы.
- Улучшение читаемости и поддержки тестов: Поскольку тесты привязаны к интерфейсам, становится легче читать и поддерживать тесты, понимая, какая бизнес-логика тестируется и какие зависимости мокируются. Это также снижает вероятность ошибки, когда реализация внешних систем меняется.
Заключение
Таким образом, главная разница в тестировании с использованием Hexagonal Architecture заключается не только в возможности мокирования, но и в создании четкой границы между бизнес-логикой и внешними зависимостями. Это улучшает тестирование, делая его более изолированным, надежным и помогающим поддерживать высокое качество кода. Если вы будете использовать архитектурный стиль Hexagonal, вы получите большие преимущества при написании тестов, которые станут более управляемыми и легко поддерживаемыми.