0Pricing
Spring Boot 4 Complete Guide · 강의

모듈 통합 테스트와 시나리오

Modulith의 시나리오 및 테스트 슬라이스 지원을 사용해 모듈 간 상호작용을 격리된 상태에서 테스트합니다.

모듈 통합 테스트와 시나리오은(는) CoddyKit의 무료 Spring Boot 4 Complete Guide 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Spring Boot 4 Complete Guide 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Module Integration Tests?

In an event-driven Modulith, modules talk to each other by publishing and consuming application events rather than calling each other directly. A unit test of a single bean can verify the publishing side, but it cannot prove that the other module actually reacts correctly.

  • Unit test — one bean, everything else mocked.
  • Module integration test — one module's Spring context, its real beans, but neighbours stubbed.
  • Full integration test — the whole application context.

Spring Modulith gives you the middle layer: spin up exactly one module, exercise its event flow, and assert what it publishes — all in isolation.

The @ApplicationModuleTest Slice

The core annotation is @ApplicationModuleTest from spring-modulith-test. It bootstraps only the module that contains the test class, not the entire application.

  • It auto-detects the module from the test's package.
  • Beans from other modules are not loaded — their events are captured instead of really handled.
  • It behaves like a Spring Boot test slice (similar to @DataJpaTest), so it is fast and focused.

Place the test in the same base package as the module under test so Modulith can resolve module boundaries correctly.

package com.example.shop.order;

import org.springframework.modulith.test.ApplicationModuleTest;

@ApplicationModuleTest
class OrderModuleIntegrationTests {

    // Only the 'order' module's beans are bootstrapped here.
    // Other modules (inventory, shipping) are NOT loaded.
}

Bootstrap Modes

@ApplicationModuleTest accepts a bootstrap mode that controls how many neighbouring modules are pulled in:

  • STANDALONE (default) — only the current module.
  • DIRECT_DEPENDENCIES — the current module plus the modules it directly depends on.
  • ALL_DEPENDENCIES — the current module and its entire transitive dependency tree.

Start with STANDALONE for the tightest isolation; widen the mode only when a test genuinely needs a real collaborator bean instead of a captured event.

import org.springframework.modulith.test.ApplicationModuleTest;
import org.springframework.modulith.test.ApplicationModuleTest.BootstrapMode;

@ApplicationModuleTest(BootstrapMode.DIRECT_DEPENDENCIES)
class OrderModuleIntegrationTests {
    // 'order' + every module it directly depends on are loaded.
}

Capturing Published Events

The simplest assertion is: did my module publish the right event? Modulith injects a PublishedEvents instance that records every event published during the test.

  • Inject it as a test parameter or autowire it.
  • Filter by type with ofType(...).
  • Refine with matching(...) on a field or predicate.

This lets you verify the publishing module's contract without loading any consumer.

@ApplicationModuleTest
class OrderModuleIntegrationTests {

    @Autowired OrderService orders;

    @Test
    void publishesEventOnCompletion(PublishedEvents events) {
        orders.complete(new OrderId("4711"));

        var completed = events.ofType(OrderCompleted.class)
                .matching(OrderCompleted::orderId, new OrderId("4711"));

        assertThat(completed).hasSize(1);
    }
}

AssertablePublishedEvents

For a more fluent, AssertJ-style API, inject AssertablePublishedEvents instead. It exposes assertThat() directly so you can chain expressive assertions.

  • contains(Type.class) — at least one event of that type.
  • matching(...) — narrow to events whose field equals a value.
  • Great for readability in larger scenarios.

Both PublishedEvents and AssertablePublishedEvents are populated by the same event-capturing infrastructure.

@Test
void completionPublishesExactlyOnce(AssertablePublishedEvents events) {
    orders.complete(new OrderId("4711"));

    assertThat(events)
            .contains(OrderCompleted.class)
            .matching(OrderCompleted::orderId, new OrderId("4711"));
}

The Scenario API

Captured events tell you what was published, but event-driven flows are often asynchronous: a stimulus triggers a listener that publishes a follow-up event. The Scenario API models exactly this stimulus → expectation shape, and it transparently waits for async work to settle.

  • stimulate(...) — the action that kicks off the flow.
  • andWaitForEventOfType(...) — block until that event appears (with a timeout).
  • toArrive() / toArriveAndVerify(...) — the terminal assertion.

Inject Scenario as a test-method parameter; you do not construct it yourself.

Stimulus Triggered by a Method Call

The most common scenario starts with a bean method invocation. Pass a lambda receiving the Scenario, call your service inside stimulate(...), then declare what event you expect downstream.

Modulith polls until the event arrives or the timeout expires — no manual Thread.sleep needed.

@ApplicationModuleTest
class OrderModuleIntegrationTests {

    @Autowired OrderService orders;

    @Test
    void completingOrderTriggersFollowUp(Scenario scenario) {
        scenario.stimulate(() -> orders.complete(new OrderId("4711")))
                .andWaitForEventOfType(OrderCompleted.class)
                .matchingMappedValue(OrderCompleted::orderId, new OrderId("4711"))
                .toArrive();
    }
}

Stimulus Triggered by Publishing an Event

To test the consuming side of a module in isolation, make the stimulus an incoming event rather than a method call. The module's listener reacts to it and (typically) publishes its own result event.

  • stimulate(event) publishes the inbound event into the context.
  • You then wait for the module's own outbound event.

This is how you verify one module's reaction to another module's event without loading that other module at all.

@Test
void inventoryReservesStockOnOrder(Scenario scenario) {
    scenario.publish(new OrderCompleted(new OrderId("4711")))
            .andWaitForEventOfType(StockReserved.class)
            .matchingMappedValue(StockReserved::orderId, new OrderId("4711"))
            .toArrive();
}

Verifying State, Not Just Events

Sometimes the assertion you really care about is a state change — a repository row, a counter, a status flag — rather than another event. toArriveAndVerify(...) runs your assertion once the awaited event has arrived.

You can also use andVerify(...) after waiting for state to stabilise. This bridges the gap between async event delivery and synchronous database checks.

@Test
void reservationPersistsState(Scenario scenario) {
    scenario.publish(new OrderCompleted(new OrderId("4711")))
            .andWaitForEventOfType(StockReserved.class)
            .toArriveAndVerify(event ->
                assertThat(reservations.findByOrderId(event.orderId()))
                        .isPresent());
}

Customising Timeouts and State Changes

Async tests need sensible timeouts. The Scenario API lets you tune the wait and even wait on arbitrary state instead of an event:

  • customize(c -> c.atMost(Duration.ofSeconds(2))) — cap the wait.
  • andWaitForStateChange(() -> repo.findStatus(id)) — poll a supplier until it returns a non-null / truthy value.

Prefer waiting for the concrete signal you care about; a generous-but-bounded timeout avoids flaky CI without masking real hangs.

@Test
void statusFlipsToShipped(Scenario scenario) {
    scenario.stimulate(() -> orders.complete(new OrderId("4711")))
            .customize(it -> it.atMost(Duration.ofSeconds(2)))
            .andWaitForStateChange(() -> orders.statusOf(new OrderId("4711")))
            .andVerify(status ->
                assertThat(status).isEqualTo(OrderStatus.SHIPPED));
}

Mocking Out-of-Module Collaborators

In STANDALONE mode, beans from other modules are absent. If your module under test directly autowires a collaborator that lives in another module (not an event-based dependency), the context cannot start. Two clean options:

  • Provide a @MockitoBean (formerly @MockBean) for that collaborator in the test.
  • Or widen the bootstrap mode to DIRECT_DEPENDENCIES so the real bean loads.

Favour the mock when you only need to stub a response; favour widening when the real collaboration is the point of the test.

@ApplicationModuleTest
class OrderModuleIntegrationTests {

    @MockitoBean PricingClient pricingClient; // bean from another module

    @Autowired OrderService orders;

    @Test
    void usesQuotedPrice(Scenario scenario) {
        when(pricingClient.quote(any())).thenReturn(Money.of(42));
        scenario.stimulate(() -> orders.place(new Cart("4711")))
                .andWaitForEventOfType(OrderPlaced.class)
                .toArrive();
    }
}

Quick Check

You want to test that the inventory module reserves stock when it receives an OrderCompleted event — without loading the order module that normally publishes it. Which approach fits best?

Recap

You learned how Spring Modulith tests cross-module event flows in isolation:

  • @ApplicationModuleTest bootstraps a single module; bootstrap modes (STANDALONE, DIRECT_DEPENDENCIES, ALL_DEPENDENCIES) control how many neighbours load.
  • PublishedEvents / AssertablePublishedEvents capture and assert what a module publishes.
  • The Scenario API models stimulus → expectation for async flows: stimulate(...) or publish(...), then andWaitForEventOfType(...) and toArrive() / toArriveAndVerify(...).
  • andWaitForStateChange(...) plus customize(...atMost...) handle state assertions and bounded timeouts.
  • Stub out-of-module collaborators with @MockitoBean, or widen the bootstrap mode when the real collaboration matters.

Together these let you prove module contracts hold without spinning up the entire application.

자주 묻는 질문

“모듈 통합 테스트와 시나리오” 강의는 무료인가요?

네 — “모듈 통합 테스트와 시나리오” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Spring Boot 4 Complete Guide 강의 전체를 잠금 해제할 수 있습니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

“모듈 통합 테스트와 시나리오”에서 뭘 배우나요?

Modulith의 시나리오 및 테스트 슬라이스 지원을 사용해 모듈 간 상호작용을 격리된 상태에서 테스트합니다. 브라우저에서 직접 실행하는 실습 코드로 Spring Boot 4 Complete Guide을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Spring Boot 4 Complete Guide을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Spring Boot 4 Complete Guide은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“모듈 통합 테스트와 시나리오” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Spring Boot 4 Complete Guide 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Spring Boot 4 Complete Guide 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. 애플리케이션 모듈과 경계 검증
  2. 애플리케이션 내부 이벤트와 리스너
  3. 트랜잭션 이벤트 발행과 아웃박스
  4. 모듈 통합 테스트와 시나리오
← Spring Boot 4 Complete Guide(으)로 돌아가기