Имеется многомодульный spring-boot проект в gradle.
Модули:
-- core (тут лежат классы, нужные сервисам, есть общие dao)
-- app-service1 (спринг-бут приложение, использующее core, тут есть специфические dao, спринг-конфигурация, конфигурация liqubase)
-- app-service2 (а тут своя конфигурация)
Сейчас я выбрал подход, что в каком модуле класс, в том и тест на него. Это приводит к тому, что в каждом модуле появляются тестовые spring конфигурации, файлы для liqubase. Сервисов много - значит будет много повторяющихся конфигураций, что плохо, конечно.
Подумываю сделать отдельный модуль для тестов, тогда вроде как будет общая на всех конфигурация. А как вы думаете?
Dmitry Roo, ну зачем тогда аннотации @SpringBootTest @ContextConfiguration придуманы?
Пишут люди тесты с конфигурациями и это ок.
Другой вопрос, что я начинаю подозревать, что у нас архитектура неправильная. Сдается мне, что в app-service не должно быть ничего кроме контроллеров и шедулеров.
Тогда все юнит-тесты поместились бы в модуле core, а вот на app-service можно натравливать интеграционные.
EVGENY T., @SpringBootTest @ContextConfiguration придуманы чтобы писать интеграционные тесты. Их пишут и это ок. Вы путаете понятия - я вам пишу только об этом.
Если у вас не получается писать юнит тесты без поднятия контекста - надо задуматься о SRP - "
принципе единственной ответственности"
Наверное, юнит тесты могут быть только в модуле и в одном пакете с кодом: им зависимости не нужны, не нужны никакие конфиги и тестовые миграции.
Интеграционные, в следствии того, что могут иметь зависимости, в т.ч. из других пакетов или охватывать функционал всего проекта вполне могут располагаться и в отдельном модуле.
Простой
