Я работаю над приложением, разделенным на модули maven следующим образом:
- myApp-parent
- framework
- module1
- module2
Первая часть: слой постоянства
Для модуля 1 / постоянство источники расположены в пакете org.company.myApp.module1.persistence, и у меня есть следующий класс конфигурации:
package org.company.myApp.module1.persistence;
import org.springframework.boot.autoconfigure.domain.EntityScan;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;
import org.springframework.data.jpa.repository.config.EnableJpaRepositories;
import org.springframework.data.ldap.repository.config.EnableLdapRepositories;
import org.company.myApp.framework.FrameworkConfiguration;
@Configuration
@Import(FrameworkConfiguration.class)
@EntityScan
@ComponentScan
@EnableLdapRepositories("org.company.myApp.module1.persistence.ldap")
@EnableJpaRepositories("org.company.myApp.module1.persistence.db")
public class Module1PersistenceConfiguration {
}
Первый вопрос : я использовал @Configuration здесь. Я не поставил @SpringBootApplication, потому что постоянство - это не отдельное приложение, а всего лишь библиотека. Тем не менее, я должен использовать @SpringBootConfiguration здесь вместо @Configuration?
Похоже, @SpringBootConfiguration это просто псевдоним @Configuration, но, несмотря на многие статьи, которые я прочитал, мне все еще неясно.
В документации указано:
Указывает, что класс предоставляет Spring Boot application @Configuration. Может использоваться в качестве альтернативы стандартной аннотации Spring @Configuration, так что конфигурация может быть найдена автоматически (например, в тестах).
Приложение должно включать только одно @SpringBootConfiguration и большинство idiomati c Spring Boot приложений. будет наследовать его от @ SpringBootApplication.
Поскольку конечное приложение со всеми модулями будет содержать несколько @SpringBootConfiguration, я выбрал простую @Configuration.
Вторая часть : тесты персистентного уровня
Источники тестов находятся в одном пакете (конечно, под src/test/java), и я сделал тест, специфицирующий c класс конфигурации:
package org.company.myApp.module1.persistence;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.ldap.LdapProperties;
import org.springframework.boot.autoconfigure.ldap.embedded.EmbeddedLdapProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.ldap.core.support.LdapContextSource;
@SpringBootApplication
public class Module1PersistenceTestConfiguration extends Module1PersistenceConfiguration {
}
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * extends Module1PersistenceConfiguration * * * * * * * * * *1067* Здесь кажется бесполезным, поскольку оба класса находятся в одном пакете, сканирование обнаружит и загрузит основную конфигурацию.
@SpringBootApplication позволяет мне загружать контекст Spring в качестве моих тестов). с помощью @SpringBootTest определить этот класс.
Второй вопрос: Если я аннотировал основную конфигурацию с помощью @SpringBootConfiguration, т он Module1PersistenceTestConfiguration был бы бесполезен? Какой здесь правильный подход?
Третья часть: уровень обслуживания
Класс конфигурации:
package org.company.myApp.module1.service;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;
import org.company.myApp.module1.persistence.Module1PersistenceConfiguration;
@Configuration
@ComponentScan
@Import(Module1PersistenceConfiguration.class)
public class Module1ServiceConfiguration {
}
Как уровень обслуживания и Слой персистентности не имеет того же пакета, я использую @Import(Module1PersistenceConfiguration.class) для запуска сканирования слоя персистентности.
Третий вопрос: Хотя я чувствую себя комфортно, возможно, есть лучшая альтернатива? Сервисный уровень должен знать о постоянном уровне и выполнить полное сканирование, добавив соответствующее свойство basePackages в @ComponentScan?
Заключительная часть: тесты сервисного уровня
Это та часть, с которой я борюсь. Я хотел бы протестировать сервисный уровень, посмеявшись над уровнем персистентности, и единственный способ сделать это - добавить класс тестовой конфигурации, который исключает основной класс конфигурации, чтобы предотвратить попытки Spring загрузить загрузочный слой (из-за @Import в основной конфигурации) и происходит сбой, так как в свойствах нет конфигурации источника данных (ресурсы персистентных тестов содержат application.properties для использования встроенной базы данных H2 и встроенного LDAP без привязки):
package org.company.myApp.module1.service;
import org.springframework.boot.SpringBootConfiguration;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.ComponentScan.Filter;
import org.springframework.context.annotation.FilterType;
@SpringBootApplication
@ComponentScan(excludeFilters = @Filter(type = FilterType.ASSIGNABLE_TYPE, value = Module1ServiceConfiguration.class))
public class Module1ServiceTestConfiguration {
}
Кроме того, я вынужден высмеивать все бины, которые поступают из слоя постоянства для каждого отдельного теста.
Последний вопрос: Каков будет правильный путь для достижения этого? Ответ может быть следующим: проводить модульное тестирование в вашей службе или интеграционное тестирование, которое включает в себя постоянный уровень, но ваши полуинтеграционные тесты не имеют никакого смысла?