Hello Axon community,
I’m trying to set up an integration (kind of) testing environment where I’ll be able to test the self-contained component through the anticorruption layer (REST API). I say integration because it’s not the full-blown API testing that runs against the real, similarly full-blown environment (for ex: k8s cluster that includes a relational database for query model and etc.), but rather idea is to include such tests in the component’s build phase (possibly with mocking out some of the irrelevant aspects) to get the feedback as early as possible.
I’m challenged by the situation where I should decide whether or not to use the real AxonServer in such tests. My initial idea was to go for this approach, cause I wanted to minimize the differences between test and real environments. But then I found that there’s no easy way (known to me) to programmatically control the lifecycle of AxonServer. I’d like to avoid calling docker or java commands from the test.
Then I decided to create a specialized Axon configuration for tests that configures in-memory event storage, and simple query/command buses
This seemed to work out pretty well until I reached the case that involves the handling of deleted aggregate root. The problem is that this error is reported differently by CommandGateway.sendAndWait depending on the environment. CommandExecutionException (as part of the CommandGateway API) is thrown in the real environment, and AggregateNotFoundException - in test env (because of the config in use).
I believe there must be a way to work around with such differences, for example by implementing custom MessageHandlerInterceptor as suggested here (I haven’t tried yet). But even if I manage to do so, I started to revisit the topic of using real AxonServer in tests. Is there a way to do so? i.e. to have a programmable variant of AxonServer that implements Axon Server API, but is relatively lightweight (for example, uses in-memory event store still).