Spring Modulith module tests: distinguish structure verification from a sliced context

Use the cheapest proof first

The downloaded Modulith project now has two classpath checks and two ApplicationModuleTest checks. The inventory slice starts Spring, constructs InventoryReservation without dispatchPlanner, then checks an accepted reservation event and a rejected command with no success event. Its state is an in-memory map; database atomicity remains untested.

Keep external work in a separate test

A module test may replace a neighboring module API with a controlled collaborator, but the real cross-module contract still needs a combined test. For asynchronous listeners, use an explicit await condition and deadline. Do not make a test pass by sleeping an arbitrary amount or by declaring a publication successful before its transaction commits. The broader test guide places those layers.

Boundary sketch

ApplicationModules.of(ReceiptModulesApplication.class).verify();
// InventoryModuleIntegrationTest also starts a sliced context.

Cost and verification

A classpath scan is cheap. A module-sliced context starts Spring infrastructure; a full application test is slower but checks the assembled graph. InventoryModuleIntegrationTest checks the sliced context; registry delivery remains untested.

Common Mistakes

• Do not call a package-only check a running integration test.
• Do not mock away the boundary under test.
• Do not infer broker delivery from a published in-process event.

Read next

Spring Modulith verification: a compiling internal import still fails architecture checks, Spring Modulith events: publish a domain fact after a valid state change, Spring tests: separate business rules, wiring and transport, Spring Boot tenant command API project: assemble the local write path.

Running module slice

Open the context boundary and the event assertion.