46.3.23 사용자 구성 및 분할

합리적인 방법으로 코드를 구성하면 기본적으로 @SpringBootApplication 클래스가 테스트 구성으로 사용됩니다.

그런 다음 기능의 특정 영역과 관련된 구성 설정으로 응용 프로그램의 기본 클래스를 낭비하지 않는 것이 중요합니다.

Spring Batch를 사용 중이며 자동 배치를 사용한다고 가정합니다. @SpringBootApplication을 다음과 같이 정의 할 수 있습니다.

스프링 배치 : 백엔드의 배치처리 기능을 구현하는 데 사용하는 프레임 워크

• 대용량 배치에 맞는 읽기 방식과 트랙잭션 처리를 간단히 구현할 수 있음

@SpringBootApplication
@EnableBatchProcessing
public class SampleApplication { ... }

이 클래스는 테스트를위한 소스 설정이기 때문에 슬라이스 테스트는 실제로 스프링 배치를 시작하려고 시도합니다. 이것은 분명히 하고 싶은 일이 아닙니다. 권장되는 방법은 해당 영역 별 구성을 응용 프로그램과 동일한 수준의 별도 @Configuration 클래스로 이동하는 것입니다 (다음 예와 같이).

@Configuration
@EnableBatchProcessing
public class BatchConfiguration { ... }

응용 프로그램의 복잡성에 따라 사용자 정의를위한 @Configuration 클래스 하나 또는 도메인 영역 당 하나의 클래스를 가질 수 있습니다. 후자의 접근법은 필요한 경우 @Import 어노테이션을 사용하여 테스트 중 하나에서이 기능을 활성화 할 수 있게 합니다. 테스트 슬라이스는 @Configuration 클래스를 검사에서 제외합니다. 예를 들어 @WebMvcTest의 경우 다음 구성은 테스트 슬라이스에 의해 로드 된 응용 프로그램 컨텍스트의 지정된 WebMvcConfigurer Bean을 포함하지 않습니다.

@Configuration
public class WebConfiguration {
	@Bean
	public WebMvcConfigurer testConfigurer() {
		return new WebMvcConfigurer() {
			...
		};
	}
}

그러나 아래의 구성은 테스트 슬라이스에 의해 사용자 지정 WebMvcConfigurer가 로드되도록 합니다.

@Component
public class TestWebMvcConfigurer extends WebMvcConfigurer {
	...
}

혼란의 또 다른 원인은 classpath 검색입니다. 코드를 합리적인 방법으로 구조화하는 동안 추가 패키지를 스캔해야 한다고 가정합니다. 응용 프로그램이 다음 코드와 유사 할 수 있습니다.

@SpringBootApplication
@ComponentScan({ "com.example.app", "org.acme.another" })
public class SampleApplication { ... }

그렇게하면 선택한 슬라이스에 상관없이 두 패키지를 검사하는 부작용이있는 기본 구성 요소 검색 지시문보다 우선 적용됩니다. 예를 들어, @DataJpaTest가 갑자기 응용 프로그램의 구성 요소 및 사용자 구성을 검색하는 것 같습니다. 다시 한 번,이 지시문을 별도의 클래스로 옮기는 것이이 문제를 해결하는 좋은 방법입니다.

이것이 옵션이 아니면 @ SpringBootConfiguration을 테스트 계층 구조의 어딘가에서 생성하여 대신 사용할 수 있습니다. 또는 테스트 소스를 지정하여 기본 소스를 찾는 동작을 비활성화 할 수 있습니다.