Spring 구성 클래스에 대한 클래스 경로 검사를 피하십시오.

Question

Spring을 사용하면 @Configuration으로 주석 처리 된 클래스를 사용하여 응용 프로그램의 다양한 측면을 구성 할 수 있습니다. 이러한 구성 클래스는 직접 가져 오거나 클래스 경로 검색을 사용하여 수집 할 수 있습니다.

클래스 경로 검색에는 특히 구성 클래스에 몇 가지 단점이있는 것으로 보입니다. 하나의 큰 단점은 다중 프로젝트 (gradle 또는 maven의 하위 프로젝트)의 경우 IDE가 클래스 패스로 갈 때 빌드 시스템에 동의하지 않는 경향이 있다는 것입니다.

특히 현재의 경우, gradle은 각 하위 프로젝트에 대한 클래스 경로 테스트 리소스 (src/main/test의 파일)를 격리합니다. 즉, 한 하위 프로젝트의 테스트가 클래스 경로 검색에서 다른 하위 프로젝트 테스트의 이것을 지정). 그러나 IntelliJ (13.1.4)는 이러한 분리를 수행하지 않으므로 테스트 결과가 gradle 및 IntelliJ에서 달라집니다. 이것은 언제든지 다시 발생할 수 있습니다 (새로운 intelliJ 또는 Eclipse 버전). 다른 버그와 마찬가지로 이것은 큰 문제입니다. 우리가 직면 한 또 다른 문제는 봄이 실행 테스트를위한 툴킷을 제공한다는 것입니다

, 그런 그들이 할 수도 교활

@RunWith(SpringJUnit4ClassRunner.class) 
@WebAppConfiguration 
public class FooTest {...} 

또는

@RunWith(SpringJUnit4ClassRunner.class) 
@ContextConfiguration 
public class FooTest {...} 

이 테스트 클래스는 클래스 패스에 결국 때문에

등 Spring Configurations로 탐지되고 사용 됨으로써 다른 테스트에 영향을줍니다.

구성을 위해 클래스 경로를 검사하는 것이 일반적으로 좋지 않습니까? 아니면 명백한 완화가 누락 되었습니까? 지금까지

Answer 1

, 나는 일반적으로 이러한 규칙에 따라, 드물게 클래스 경로 검색을 사용

이

• 구성을은 동일한 모듈에 패키지를 스캔해야
• configuratino는 그 자체 또는 하위 패키지
스캔한다

다른 구성을 대상으로하는 @Import를 사용하는 것이 훨씬 더 좋습니다. 그것은 의도와 의존성을 훨씬 더 명백하게 만들고 클래스 패스 문제를 피하는 데 도움이됩니다.