axonhub - spring integration testing

I watched the (great) Live demo

and began to wonder: the demo shows the split-up of the ui/query/command parts into separate services using spring profiles.

Will I still be able to i-test an application that uses axonhub by switching back to the “all parts in one application” behaviour, or will I require access to an axonhub during i-tests?

What are possible strategies here?

Hi Jan,

Great that you liked the demo.

Yes, you can run tests in a monolithic form without AxonHub, but practically you’d have to be aware of the following (assuming Spring Boot): once you have the axonhub-spring-boot-autoconfigure dependency on your classpath, you will get AxonHub versions of the 3 buses, and the system won’t work anymore without AxonHub.

One way of dealing with this would be to activate AxonHub usage through a separate profile (for instance called “axonhub”) and then enabling or disabling AxonHub autoconfiguration based on the profile.

This demo: has code like that, specifically in AxonCasinoApplication.kt it has

class EnableHubAutoconfig

@EnableAutoConfiguration(exclude = arrayOf(MessagingAutoConfiguration::class, EventStoreAutoConfiguration::class, SubscriptionQueryAutoConfiguration::class))
class DisableHubAutoconfig

This demo can run as a monolith using only an embedded H2 database, but also fully scaled out using AxonHub + AxonDB, and MySQL for the read models, saga store and scheduling.

One side note about the whole strategy with profiles to enable microservices: this is something we mainly started doing for quick demos. In the real world, key drivers for using microservices would be agility (changing a single service) and scalability. The strategy with the profile does enable the latter, but it doesn’t really work towards agility since it promotes the use of a single code base. So my guess would be that it is not the best strategy for most real-life scenarios.