Spring Modulith
에서는@ApplicationModuleTest
가 선언된 테스트에 Scenario
를 파라미터로 전달한다.
Scenario
는 아래 단계를 정의하고 정의를 안내하는 API를 노출한다.
- 시스템에 대한 자극(stimulus, publish)을 정의한다. 일반적으로 이벤트 게시 또는 모듈에 의해 노출된 Spring 구성 요소의 호출이 해당한다.
- 실행의 기술적 세부 사항(시간 초과 등)의 선택적 사용자 정의한다.
- 어떤 예상된 결과를 정의한다. 특정 조건을 만족하는 또 다른 애플리케이션 이벤트가 발생하거나, 모듈의 상태 변화가 발생하여 이를 공개된 컴포넌트를 호출함으로써 감지할 수 있는 것을 의미한다.
- 수신된 이벤트 또는 관찰된 변경된 상태를 확인한다.(선택 사항)
Scenario 시작 (1)
// Start with an event publication
scenario.publish(new MyApplicationEvent(…)).…
// Start with a bean invocation
scenario.stimulate(() -> someBean.someMethod(…)).…
이벤트 게시와 빈 호출은 모두 트랜잭션 콜백 내에서 발생하여 지정된 이벤트 또는 빈 호출 중에 게시된 모든 이벤트가 트랜잭션 이벤트 리스너에 전달된다.
이때 테스트 케이스가 이미 트랜잭션 내에서 실행 중인지 여부에 관계없이 새 트랜잭션이 시작된다.
즉, 자극에 의해 트리거된 데이터베이스의 상태 변경은 절대 롤백되지 않으며 수동으로 정리해야 한다. cc. .andCleanUp(...)
Scenario 정의 (2)
.customize(...)
메서드를 통해 실행을 사용자 지정하거나 타임아웃 설정과 같은 일반적인 사용 사례를 위한 특수 메서드 .waitAtMost(...)
를 통해 실행을 사용자 정의할 수 있다.
….andWaitForEventOfType(SomeOtherEvent.class)
.matching(event -> …) // Use some predicate here
.…
그리고 특정 유형의 이벤트 혹은 매처를 사용한 추가적 제한을 통해 결과의 기대값을 추가 정의할 수 있다.
Scenario 예상 (3) & 검증 (4)
// Executes the scenario
….toArrive(…)
// Execute and define assertions on the event received
….toArriveAndVerify(event -> …)
완료 조건은 .toArrive()
와 같은 종단 연산자를 사용하여 설정하며, 이를 통해 예상된 이벤트나 빈 호출의 결과에 접근하고 검증할 수 있다.
scenario.publish(new MyApplicationEvent(…))
.andWaitForStateChange(() -> someBean.someMethod(…)))
.andVerify(result -> …);
혹은 이벤트 게시가 예상 완료 신호로 작동하는 대신, 이벤트 발행 후의 상태 변경을 감지하기 위해 노출된 컴포넌트 중 하나에서 메서드를 호출하여 애플리케이션 모듈의 상태를 검사할 수도 있다..andWaitForStateChange(..., Predicate)
에서는 기본적으로 null
이 아닌 값과 비어 있지 않은 Optional
값을 .andVerify(...)
메서드로 전달한다.
참조 문서: https://docs.spring.io/spring-modulith/reference/testing.html
Integration Testing Application Modules :: Spring Modulith
Integration testing application modules can become a quite elaborate effort. Especially if the integration of those is based on asynchronous, transactional event handling, dealing with the concurrent execution can be subject to subtle errors. Also, it requ
docs.spring.io
'스프링' 카테고리의 다른 글
트랜잭션 커밋과 AOP 중 어떤 것이 먼저 실행 될까? (0) | 2025.03.15 |
---|---|
Parallel Test Execution (0) | 2025.03.13 |
@EnableJpaRepositories (0) | 2025.03.03 |
BeanPostProcessor (1) | 2025.01.16 |
@Async 정리 (1) | 2025.01.02 |
Spring Modulith
에서는@ApplicationModuleTest
가 선언된 테스트에 Scenario
를 파라미터로 전달한다.
Scenario
는 아래 단계를 정의하고 정의를 안내하는 API를 노출한다.
- 시스템에 대한 자극(stimulus, publish)을 정의한다. 일반적으로 이벤트 게시 또는 모듈에 의해 노출된 Spring 구성 요소의 호출이 해당한다.
- 실행의 기술적 세부 사항(시간 초과 등)의 선택적 사용자 정의한다.
- 어떤 예상된 결과를 정의한다. 특정 조건을 만족하는 또 다른 애플리케이션 이벤트가 발생하거나, 모듈의 상태 변화가 발생하여 이를 공개된 컴포넌트를 호출함으로써 감지할 수 있는 것을 의미한다.
- 수신된 이벤트 또는 관찰된 변경된 상태를 확인한다.(선택 사항)
Scenario 시작 (1)
// Start with an event publication
scenario.publish(new MyApplicationEvent(…)).…
// Start with a bean invocation
scenario.stimulate(() -> someBean.someMethod(…)).…
이벤트 게시와 빈 호출은 모두 트랜잭션 콜백 내에서 발생하여 지정된 이벤트 또는 빈 호출 중에 게시된 모든 이벤트가 트랜잭션 이벤트 리스너에 전달된다.
이때 테스트 케이스가 이미 트랜잭션 내에서 실행 중인지 여부에 관계없이 새 트랜잭션이 시작된다.
즉, 자극에 의해 트리거된 데이터베이스의 상태 변경은 절대 롤백되지 않으며 수동으로 정리해야 한다. cc. .andCleanUp(...)
Scenario 정의 (2)
.customize(...)
메서드를 통해 실행을 사용자 지정하거나 타임아웃 설정과 같은 일반적인 사용 사례를 위한 특수 메서드 .waitAtMost(...)
를 통해 실행을 사용자 정의할 수 있다.
….andWaitForEventOfType(SomeOtherEvent.class)
.matching(event -> …) // Use some predicate here
.…
그리고 특정 유형의 이벤트 혹은 매처를 사용한 추가적 제한을 통해 결과의 기대값을 추가 정의할 수 있다.
Scenario 예상 (3) & 검증 (4)
// Executes the scenario
….toArrive(…)
// Execute and define assertions on the event received
….toArriveAndVerify(event -> …)
완료 조건은 .toArrive()
와 같은 종단 연산자를 사용하여 설정하며, 이를 통해 예상된 이벤트나 빈 호출의 결과에 접근하고 검증할 수 있다.
scenario.publish(new MyApplicationEvent(…))
.andWaitForStateChange(() -> someBean.someMethod(…)))
.andVerify(result -> …);
혹은 이벤트 게시가 예상 완료 신호로 작동하는 대신, 이벤트 발행 후의 상태 변경을 감지하기 위해 노출된 컴포넌트 중 하나에서 메서드를 호출하여 애플리케이션 모듈의 상태를 검사할 수도 있다..andWaitForStateChange(..., Predicate)
에서는 기본적으로 null
이 아닌 값과 비어 있지 않은 Optional
값을 .andVerify(...)
메서드로 전달한다.
참조 문서: https://docs.spring.io/spring-modulith/reference/testing.html
Integration Testing Application Modules :: Spring Modulith
Integration testing application modules can become a quite elaborate effort. Especially if the integration of those is based on asynchronous, transactional event handling, dealing with the concurrent execution can be subject to subtle errors. Also, it requ
docs.spring.io
'스프링' 카테고리의 다른 글
트랜잭션 커밋과 AOP 중 어떤 것이 먼저 실행 될까? (0) | 2025.03.15 |
---|---|
Parallel Test Execution (0) | 2025.03.13 |
@EnableJpaRepositories (0) | 2025.03.03 |
BeanPostProcessor (1) | 2025.01.16 |
@Async 정리 (1) | 2025.01.02 |