Testing

Spring DDD applications have a few distinct testing concerns that call for different strategies.

Event-sourced aggregates are plain Kotlin objects, so both halves of their behaviour — the events a command records and the state those events fold to — are unit-testable with no Spring context, no repository, and no database. The aggregate test fixture (Testing aggregates) drives a command and asserts both, keeping these tests fast and deterministic.

Sagas are plain objects too: their event and deadline handlers can be called directly with test doubles for the command gateway and other collaborators, while the lifecycle — starting, association, completion, and deadline firing — is driven by the framework and verified in an integration test.

Projections apply events after the transaction that recorded them commits, on a thread of their own. An integration test waits for a projection with Waiting for projections before it asserts on a read model. Database cleanup empties the data Spring DDD keeps between integration tests, so the tests stay independent without touching your own application tables.