TIL

4. Integration Testing Application Modules

https://docs.spring.io/spring-modulith/reference/testing.html

• Spring Modulith를 사용하면 각 애플리케이션 모듈을 단독으로 또는 다른 모듈과 조합하여 부트스트랩하는 통합 테스트를 실행할 수 있다.
• 애플리케이션 모듈 패키지 또는 그 하위 패키지에 JUnit 테스트 클래스를 배치한 뒤 @ApplicationModuleTest 애너테이션을 달면 된다.

package example.order

@ApplicationModuleTest
class OrderIntegrationTests {

  // Individual test cases go here
}

• @SpringBootTest와 유사한 통합 테스트가 실행된다.
  • 그러나 실제로는 테스트가 상주하는 애플리케이션 모듈로 제한된다.
• org.springframework.modulith=DEBUG로 설정하면 스프링부트 부트스트랩을 정의하는 방법에 대한 자세한 정보를 알 수 있다.
  • 콘솔 로그에 모듈에 대한 자세한 정보가 표시될 것이다.

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::       (v3.0.0-SNAPSHOT)

… - Bootstrapping @ApplicationModuleTest for example.order in mode STANDALONE (class example.Application)…
… - ======================================================================================================
… - ## example.order ##
… - > Logical name: order
… - > Base package: example.order
… - > Direct module dependencies: none
… - > Spring beans:
… -       + ….OrderManagement
… -       + ….internal.OrderInternal
… - Starting OrderIntegrationTests using Java 17.0.3 …
… - No active profile set, falling back to 1 default profile: "default"
… - Re-configuring auto-configuration and entity scan packages to: example.order.

부트스트랩 모드

• 애플리케이션 모듈 테스트는 다양한 모드를 제공한다.
  • STANDALONE (default) - 현재 모듈만 수행
  • DIRECT_DEPENDENCIES - 현재 모듈 그리고 직접적인 의존이 있는 모듈만 수행
  • ALL_DEPENDENCIES - 의존 관계가 있는 전체 모듈 트리에 대해 수행

효과적인 의존성 다루기

• 애플리케이션 모듈이 부트스트랩되면 해당 모듈의 스프링 빈이 인스턴스화된다.
• 모듈 경계를 넘나드는 빈 참조가 있는 경우 다른 모듈이 테스트 실행에 포함되지 않으면 부트스트랩이 실패한다.
• 다른 모듈까지 범위를 확장할 수도 있지만 일반적으로 대상 빈을 모킹하는 것이 더 나은 옵션이다.
  • ex) @MockBean 사용
• 애플리케이션 모듈이 다른 모듈 빈에 너무 많이 의존하는 경우 일반적으로 결합이 높다는 신호
  • 이러한 의존성은 도메인 이벤트를 통해 대체할 수 없는지 검토해봐야 한다.

통합 테스트 시나리오 정의

• 애플리케이션 모듈들을 대상으로 하는 통합 테스트는 정교한 조정이 필요하다.
  • 특히 비동기 트랜잭션 이벤트 처리를 기반으로 하는 경우 미묘한 오류가 발생할 수 있다.
  • 꽤 많은 인프라 구성 요소를 처리해야할 때도 번거롭다.
• 물론 이를 테스트할 수 있는 도구들이 존재한다.
  • TransactionOperations 및 ApplicationEventProcessor - 트랜잭션 리스너에 이벤트가 게시되고 전달되는지 확인
  • Awaitility - 동시성 처리
• 모듈 통합 테스트 정의를 쉽게 하기 위해 Spring Modulith는 Scenario 추상화를 제공한다.
  • 이를 @ApplicationModuleTest로 선언된 테스트에서 메서드 파라미터로 사용 가능

@ApplicationModuleTest
class SomeApplicationModuleTest {

  @Test
  fun someModuleIntegrationTest(scenario: Scenario) {
    // Use the Scenario API to define your integration test
  }
}

• 테스트 정의 자체는 일반적으로 아래 골격을 따른다.
  1. 시스템에 대한 자극을 정의하는데 이는 일반적으로 이벤트 발행 또는 모듈에 의해 노출된 스프링 구성요소의 호출을 의미한다.
  2. 실행의 기술적 세부 사항 (타임아웃 등)을 선택적으로 커스터마이징
  3. 애플리케이션 이벤트가 발생하거나, 모듈에서 노출된 구성 요소를 호출함으로써 감지할 수 있는 모듈 상태 변화와 같은 기대 결과의 정의
  4. 수신된 이벤트 또는 감지된 변경된 상태에 대한 선택적 추가 검증
• Scenario는 이러한 단계를 정의하고 안내하는 API를 제공한다.

// Start with an event publication
scenario.publish(MyApplicationEvent(…)).…

// Start with a bean invocation
scenario.stimulate(() -> someBean.someMethod(…)).…

• 이벤트 발행과 빈 호출 모두 트랜잭션 콜백 내에서 발생하여 이벤트 또는 빈 호출 중에 발행된 이벤트가 트랜잭션 이벤트 리스너에 전달되도록 한다.
• 테스트가 이미 트랜잭션 내에서 실행 중인지 여부에 관계 없이 새 트랜잭션을 시작한다는 점에 유의하라
  • 즉 여기서 발생한 변경사항은 롤백되지 않기에 수동으로 정리해야 한다.
• 결과 오브젝트는 …customize(…) 메서드를 통해 실행을 커스터마이징하거나 타임아웃 설정을 위한 특수 메서드 (…waitAtMost(…))를 통해 커스터마이징 할 수 있다.
• 셋업 단계는 자극의 결과에 대한 기대치를 정의하는 것으로 마무리된다.
  • 특정 유형의 이벤트 등
• 아래 코드는 matcher에 의해 선택적 추가 제한을 설정하는 코드다.
  • 최종 실행이 진행되기 위해 대기를 하게 되며 완료 기준을 설정한다.
  • 아래 코드에선 SomeOtherEvent가 발행되거나 타임아웃 될 때까지 실행이 차단된다.

….andWaitForEventOfType(SomeOtherEvent.class)
 .matching(event -> …) // Use some predicate here
 .…

• …toArrive…()
  • 이벤트 기반 시나리오를 실행하는 작업의 이름
  • 발행된 예상 이벤트 또는 원래 자극에 정의된 빈 호출 결과 오브젝트에 선택적으로 엑세스 가능

// Executes the scenario
….toArrive(…)

// Execute and define assertions on the event received
….toArriveAndVerify(event -> …)

• 메서드 이름이 이상해보일 순 있지만 결합한다면 꽤 잘 읽힌다.

scenario.publish(new MyApplicationEvent(…))
  .andWaitForEventOfType(SomeOtherEvent::class)
  .matching(event -> …)
  .toArriveAndVerify(event -> …)

• 이벤트 발행 뿐 아니라 노출된 컴포넌트 중 한 메서드를 호출하여 애플리케이션 모듈의 상태를 검증할 수도 있다.
  • 상태 변경을 감지하기 위해 메서드 호출이 반환하는 값은 …andVerify(…) 메서드로 전달된 결과다.

scenario.publish(new MyApplicationEvent(…))
  .andWaitForStateChange(() -> someBean.someMethod(…)))
  .andVerify(result -> …)

• 기본적으로 non-null 값과 empty가 아닌 Optional 값은 결정적인 상태 변경으로 간주된다.
  • 이는 …andWaitForStateChange(…, Predicate)로 조정할 수 있다.

Scenario 실행 커스터마이징

• 개별 Scenario를 커스터마이징 하려면 customize(…) 메서드를 호출하면 된다.

scenario.publish(MyApplicationEvent(…))
  .customize(it -> it.atMost(Duration.ofSeconds(2)))
  .andWaitForEventOfType(SomeOtherEvent::class)
  .matching(event -> …)
  .toArriveAndVerify(event -> …)

• 테스트 클래스의 모든 Senario 인스턴스를 전역적으로 사용하는 방법도 존재한다.

@ExtendWith(MyCustomizer::class)
class MyTests {

  @Test
  fun myTestCase(scenario : Scenario) {
    // scenario will be pre-customized with logic defined in MyCustomizer
  }

  class MyCustomizer : ScenarioCustomizer {

    override fun getDefaultCustomizer(method : Method, context : ApplicationContext) : Function<ConditionFactory, ConditionFactory> {
      return it -> …
    }
  }
}