TestExecutionListener Configuration

Spring은 기본적으로 다음과 같은 TestExecutionListener implementation들을 정확히 다음 순서대로 등록합니다.

• ServletTestExecutionListener: WebApplicationContext를 위해 Servlet API mock을 구성합니다.
• DirtiesContextBeforeModesTestExecutionListener: "before" mode에 대한 @DirtiesContext 어노테이션을 처리합니다.
• ApplicationEventsTestExecutionListener: ApplicationEvents에 대한 지원을 제공합니다.
• BeanOverrideTestExecutionListener: Bean Overriding in Tests에 대한 지원을 제공합니다.
• DependencyInjectionTestExecutionListener: test 인스턴스에 대해 의존성 주입을 제공합니다.
• MicrometerObservationRegistryTestExecutionListener: Micrometer의 ObservationRegistry에 대한 지원을 제공합니다.
• DirtiesContextTestExecutionListener: "after" mode에 대한 @DirtiesContext 어노테이션을 처리합니다.
• CommonCachesTestExecutionListener: 필요한 경우 test의 ApplicationContext에서 resource 캐시를 비웁니다.
• TransactionalTestExecutionListener: 기본 롤백 의미 체계를 사용하여 트랜잭션 test 실행을 제공합니다.
• SqlScriptsTestExecutionListener: @Sql 어노테이션을 사용하여 구성된 SQL 스크립트를 실행합니다.
• EventPublishingTestExecutionListener: test의 ApplicationContext에 test 실행 이벤트를 publish합니다(Test Execution Events 참조).
• MockitoResetTestExecutionListener: @MockitoBean 또는 @MockitoSpyBean에 의해 구성된 mock을 reset합니다.

Registering TestExecutionListener Implementations

@TestExecutionListeners 어노테이션을 사용하여 test 클래스, 그 서브클래스, 그리고 중첩 클래스에 대해 TestExecutionListener implementation을 명시적으로 등록할 수 있습니다. 자세한 내용과 예시는 annotation support 및 @TestExecutionListeners의 javadoc을 참조하십시오.

기본 TestExecutionListener implementation으로 전환하기 @TestExecutionListeners가 어노테이션된 클래스를 상속하고 기본 listener 집합을 사용하도록 전환해야 하는 경우, 다음과 같이 클래스에 어노테이션을 추가할 수 있습니다.

1// Switch to default listeners
2@TestExecutionListeners(
3	listeners = {},
4	inheritListeners = false,
5	mergeMode = MERGE_WITH_DEFAULTS)
6class MyTest extends BaseTest {
7	// class body...
8}

1// Switch to default listeners
2@TestExecutionListeners(
3	listeners = [],
4	inheritListeners = false,
5	mergeMode = MERGE_WITH_DEFAULTS)
6class MyTest : BaseTest {
7	// class body...
8}

Automatic Discovery of Default TestExecutionListener Implementations

@TestExecutionListeners를 사용하여 TestExecutionListener implementation을 등록하는 것은 제한된 테스트 시나리오에서 사용되는 커스텀 listener에 적합합니다. 그러나 커스텀 listener를 전체 test suite에서 사용해야 하는 경우에는 번거로울 수 있습니다.

이 문제는 SpringFactoriesLoader 메커니즘을 통한 기본 TestExecutionListener implementation의 자동 검색 지원을 통해 해결됩니다.

예를 들어, spring-test 모듈은 META-INF/spring.factories properties 파일에서 org.springframework.test.context.TestExecutionListener key 아래에 모든 코어 기본 TestExecutionListener implementation을 선언합니다. 서드파티 프레임워크와 개발자는 자신의 spring.factories 파일을 통해 동일한 방식으로 기본 listener 목록에 자신들의 TestExecutionListener implementation을 추가할 수 있습니다.

Ordering TestExecutionListener Implementations

TestContext 프레임워크가 앞에서 언급한 SpringFactoriesLoader 메커니즘을 통해 기본 TestExecutionListener implementation을 발견하면, 인스턴스화된 listener들은 Spring의 AnnotationAwareOrderComparator를 사용하여 정렬되며, 이는 정렬을 위해 Spring의 Ordered 인터페이스와 @Order 어노테이션을 적용합니다.

AbstractTestExecutionListener와 Spring이 제공하는 모든 기본 TestExecutionListener implementation은 적절한 값으로 Ordered를 구현합니다. 따라서 서드파티 프레임워크와 개발자는 자신들의 기본 TestExecutionListener implementation이 Ordered를 구현하거나 @Order를 선언하여 올바른 순서로 등록되도록 해야 합니다. 각 코어 listener에 어떤 값이 할당되는지에 대한 자세한 내용은 코어 기본 TestExecutionListener implementation의 getOrder() 메서드에 대한 javadoc을 참조하십시오.

Merging TestExecutionListener Implementations

커스텀 TestExecutionListener가 @TestExecutionListeners를 통해 등록되면 기본 listener는 등록되지 않습니다. 대부분의 일반적인 테스트 시나리오에서는 개발자가 커스텀 listener 외에 모든 기본 listener를 수동으로 선언해야 합니다.

다음 listing은 이러한 스타일의 구성을 보여줍니다.

1@ContextConfiguration
2@TestExecutionListeners({
3	MyCustomTestExecutionListener.class,
4	ServletTestExecutionListener.class,
5	DirtiesContextBeforeModesTestExecutionListener.class,
6	DependencyInjectionTestExecutionListener.class,
7	DirtiesContextTestExecutionListener.class,
8	TransactionalTestExecutionListener.class,
9	SqlScriptsTestExecutionListener.class
10})
11class MyTest {
12	// class body...
13}
14// Copied!

1@ContextConfiguration
2@TestExecutionListeners(
3	MyCustomTestExecutionListener::class,
4	ServletTestExecutionListener::class,
5	DirtiesContextBeforeModesTestExecutionListener::class,
6	DependencyInjectionTestExecutionListener::class,
7	DirtiesContextTestExecutionListener::class,
8	TransactionalTestExecutionListener::class,
9	SqlScriptsTestExecutionListener::class
10)
11class MyTest {
12	// class body...
13}
14// Copied!

이 접근 방식의 문제는 개발자가 기본적으로 어떤 listener가 등록되는지 정확히 알고 있어야 한다는 점입니다. 더욱이, 기본 listener 집합은 릴리스마다 변경될 수 있습니다.

예를 들어, SqlScriptsTestExecutionListener는 Spring Framework 4.1에서 도입되었고, DirtiesContextBeforeModesTestExecutionListener는 Spring Framework 4.2에서 도입되었습니다. 또한 Spring Boot와 Spring Security와 같은 서드파티 프레임워크는 앞에서 언급한 automatic discovery mechanism을 사용하여 자신들의 기본 TestExecutionListener implementation을 등록합니다.

모든 기본 listener를 인지하고 다시 선언해야 하는 것을 피하기 위해, @TestExecutionListeners의 mergeMode 속성을 MergeMode.MERGE_WITH_DEFAULTS로 설정할 수 있습니다. MERGE_WITH_DEFAULTS는 로컬로 선언된 listener가 기본 listener와 merge되어야 함을 나타냅니다.

Merging 알고리즘은 목록에서 중복을 제거하고, Ordering TestExecutionListener Implementations에 설명된 대로 AnnotationAwareOrderComparator의 의미 체계에 따라 merge된 listener 집합이 정렬되도록 보장합니다. Listener가 Ordered를 구현하거나 @Order로 어노테이션된 경우, 기본 listener와 merge되는 위치에 영향을 줄 수 있습니다. 그렇지 않으면, 로컬로 선언된 listener는 merge 시 기본 listener 목록의 끝에 추가됩니다.

예를 들어, 이전 예제의 MyCustomTestExecutionListener 클래스가 자신의 order 값을(예: 500) ServletTestExecutionListener(우연히도 1000)의 order보다 작도록 구성하면, MyCustomTestExecutionListener는 기본 목록에서 ServletTestExecutionListener 앞에 자동으로 merge될 수 있으며, 이전 예제는 다음과 같이 대체될 수 있습니다.

1@ContextConfiguration
2@TestExecutionListeners(
3	listeners = MyCustomTestExecutionListener.class,
4	mergeMode = MERGE_WITH_DEFAULTS
5)
6class MyTest {
7	// class body...
8}
9// Copied!

1@ContextConfiguration
2@TestExecutionListeners(
3	listeners = [MyCustomTestExecutionListener::class],
4	mergeMode = MERGE_WITH_DEFAULTS
5)
6class MyTest {
7	// class body...
8}
9// Copied!