Module Integration Testing and Scenarios
Test cross-module interactions in isolation using Modulith's scenario and test-slice support.
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.
}All lessons in this course
- Application Modules and Boundary Verification
- Internal Application Events and Listeners
- Transactional Event Publication and Outbox
- Module Integration Testing and Scenarios