Package org.axonframework.test.fixture

Class AxonTestFixture

java.lang.Object
org.axonframework.test.fixture.AxonTestFixture
All Implemented Interfaces:
AxonTestPhase.Setup
public class AxonTestFixture extends Object implements AxonTestPhase.Setup
Fixture for testing Axon Framework application. The fixture can be configured to use your whole application configuration or just a portion of that (single module or component). The fixture allows the execution of given-when-then style.

Decorator chain architecture and the two-reference design

The fixture maintains two separate references for both the command bus and the event infrastructure:

  1. Outermost references (commandBus, eventSink) — obtained from the configuration via configuration.getComponent(...). These sit at the top of the decorator chain and are used by the given-phase and when-phase to dispatch commands and publish events. Dispatching through the outermost reference ensures that the message traverses all decorators, including dispatch interceptors that enrich messages with correlation metadata, tracing headers, etc.
  2. Innermost recording references (recordingCommandBus, recordingEventSink) — created by MessagesRecordingConfigurationEnhancer as the innermost decorators (DECORATION_ORDER = Integer.MIN_VALUE). These are used by the then-phase to assert on recorded messages. Because they sit at the bottom of the decorator chain, they capture messages after all dispatch interceptors have enriched them.

For commands, the decorator chain looks like: 

   commandBus (outermost, for dispatching)
     → InterceptingCommandBus (applies dispatch interceptors, enriches metadata)
       → recordingCommandBus (innermost, captures post-interceptor commands for assertions)
         → raw CommandBus implementation

For events, the same pattern applies. The concrete type depends on the configuration:

  • With EventSourcingConfigurer — an EventStore is present, so the chain is: 
       eventSink (outermost EventStore, for publishing)
     → InterceptingEventStore (applies dispatch interceptors)
       → RecordingEventStore (innermost, captures post-interceptor events for assertions)
         → raw EventStore implementation
  • With MessagingConfigurer (no event sourcing) — an EventBus is present, so the chain is: 
       eventSink (outermost EventBus, for publishing)
     → InterceptingEventBus (applies dispatch interceptors)
       → RecordingEventBus (innermost, captures post-interceptor events for assertions)
         → raw EventBus implementation (e.g. SimpleEventBus)
Both RecordingEventStore and RecordingEventBus implement RecordingEventSink, so they are held uniformly as recordingEventSink regardless of the event infrastructure variant.

Why two references are necessary: If recording were at the outermost position, the recorder would capture the original, un-enriched message (before dispatch interceptors run). By placing recording at the innermost position, the recorder sees the fully enriched message — but we can no longer use the same reference for dispatching, because dispatching through the innermost reference would skip the interceptors. Hence the fixture keeps both: the outermost for dispatching and the innermost for assertions.

Since:
5.0.0
Author:
Allard Buijze, Mateusz Nowak, Mitchell Herrijgers, Steven van Beelen