Spring Boot Testing

Axon Framework
1

The university example doesn’t seem to contain the test fixture and I was looking at using the spring boot starter, but as soon as autoconfigure is added to my classpath it expects the server to be configured which is expected (but not desirable).

I’m sitting here trying to figure out what is the minimum I need to do to get an AxonTestFixture working.

@EventSourced
class RegistrationCommandHandler {
  @CommandHandler
  static void handle(
    RegisterNewUser command,
    EventAppender eventAppender
  ) {
    var event = new UserCreated(User.UserId.create());
    eventAppender.append(event);
  }
}

class RegisterNewUserTest {

  private AxonTestFixture fixture;

  @BeforeEach
  void beforeEach() {
    fixture = AxonTestFixture.with(EventSourcingConfigurer.create());
  }

  @AfterEach
  void afterEach() {
    fixture.stop();
  }

  @Test
  void register() throws AddressException {
    var registration = RegisterNewUser.builder()
      .subject(new OIDCSubject("google:12345"))
      .issuer(URI.create("https://example.com"))
      .email(new InternetAddress("xenoterracide@gmail.com"))
      .emailVerified(true)
      .build();

    fixture.given().when().command(registration).then().success();
  }
}
2

I think this section of the Reference Guide helps you to spot how to customize your fixtures.
On top of that, [this section](Advanced Testing) should give you more on how to use Spring Boot in combination with test fixtures.

3

Ow, and once this PR is merged, it will be even easier to test with Spring Boot and Axon Framework :slight_smile:

4 
customization.disableAxonServer()

yeah, instead of doing this I ended up filtering the connector out of the autoconfigure dependencies. worked wonders.

probably should be a provided/optional dependency of autoconfigure in 5.1. then with the test starter in the PR (which could not have that) and the regular starter which could have it but not transiently through autoconfigure. Also I haven’t fully read that PR but the test starter autoconfigure should automatically turn off the requirement.

5

Given that we’re the maintainers of Axon Server, I can assure you that we’re not going to make Axon Server an optional component of the Axon Framework. We view Axon Server as the sane default for Event Storage and Distributed Messaging when using Axon Framework. These are the reasons Axoniq was founded 8 years ago. Differently put, we’ve built it for a reason, based on previous experiences before Axon Server existed.

So, any solution in Axon Framework will anticipate Axon Server to be used. If the user does not desire to use it, that’ll be a conscious adjustment the user needs to make.

View it as a car company like Toyota that does not recommend Toyota parts. That’s not something that’s going to happen, as you can imagine.

Regardless, thanks for your point of view @xenoterracide. I trust you understand our point of view.

6

Well then you should consider improving the behavior of the framework so that it doesn’t automatically break test fixtures. This is surprising behavior in a spring boot environment. Where my tests automatically break as soon as I brought the starter on when the documentation says that there is an in-memory configuration that is used by tests. Especially when simply not having the connector removes the issue. If I do spring data jpa starter it automatically uses H2 for testing if it’s available. Same principle applies. Having an unfriendly developer experience does not give you more credit.

It should be an optional dependency for testing; or you know at least not break the testing environment by trying to force you to set up a server that you might not want at that point in the. especially since the tutorial doesn’t cover how to deal with it. Technically speaking my understanding is that it’s optional for production too… at that point though it’s a lot of grow your own components. Which is fine.

My software layout has easily 10 modules right now. Since each domain module has to have this for testing But doesn’t need to connect to the real database it’s a waste of a dependency. Now when I get to the more end-end testing I’m going to need to stay on the server up. I don’t want to spend a lot of time writing code in every single one of these isolated domain modules avoiding the connector breaking the workflow in an environment where I don’t need it yet. The spring boot auto configuration obviously works without it. Which means that the auto configuration shouldn’t have a required dependency on it to begin with. Whether or not the starter does is another thing especially if you add a test starter. I have a tendency not to use spring boot starters because they add dependencies I don’t want in places I don’t want them but if your auto configuration is also doing that and I have to exclude things that’s a problem. I haven’t experienced this problem in other frameworks (spring boot or otherwise), so it’s indicative of quality especially the pushback.

Also lecturing about how Toyota blah blah blah… think about how Toyota actually won the US market. One by having really good cars two selling them for cheaper than US automakers could compete with. This is a pretty toxic rant you’re on. I suggest focusing on the quality of the tool.

7

btw Basic Testing with AxonTestFixture this doesn’t actually seem to exist in axon 5 (the junit extension), I don’t know if it existed in axon 4

8

to be clear, no one is suggesting that toyota not recommend toyota parts. However if I buy the toyota engine it shouldn’t ship with the toyota transmission. more concretely Application Design Problems Solved by Axon Framework 5 this says

adding the axon-server-connector dependency automatically enables Axon Server in tests.

but the spring boot autoconfiguration dependencies forces it to be added (even though that code obviously doesn’t require it) and thus makes this statement false

has been enhanced to work seamlessly with both in-memory Event Store and Axon Server. The same test code can run against either environment,

because you’ve effectively made the “in memory store” not exist by forcing me to exclude the dependency after adding the auto configuration.

the referenced PR looks like it will help a lot. However this, likely, still causes a problem that is fixed if the starter includes this, and the test starter does not.

Additionally, right now the documentation seems to do a really good job of mixing axon 4 and axon 5, which is hard to understand. It looks like axon 5 is 100% backwards incompatible. I’m in a state of trying to learn something and the documentation contradicts itself. General internet won’t have valid documentation (thus breaking AI too) because it’s all out of date. So I’m frustrated and finding myself in a … well this doesn’t seem to be the right tool scenario.

9

I note I hit a snag with you, @xenoterracide. My apologies for that! I did not mean it to come across as a, as you word it, “toxic rant.” There are simply a lot of moving parts to act on; sometimes I can’t do everything the justice it deserves. Next to that, although I am not sure, your reply (especially as it’s three distinct comments on this thread) seem to hint towards a “toxic rant reply”, if anything. Thus, I would hope you similarly comprehend that how your communication style comes across is, well, unkind.

But, that’s internet communication for you. Again, my apologies if my wording came across as harsh. That’s unfair and unhelpful.

What I do need to stress again, in my honest opinion, is the fact that Axon Framework will not switch the default away. That’s simply not a choice we can or will make.

What that said, I think we can move back to the request at hand, which is Spring Boot Testing with Axon Framework 5.

Making it a straightforward choice to toggle it off for the user, as well as clear documentation, those are indeed pointers of improvement. From a testing perspective, I believe disabling it actually is straightforward, through the referred to Customization of the AxonTestFixture. But, I “guess” (so please correct me if I am wrong) that you’d hope that the axon-testing module would automatically disable the Axon Server logic if the axon-server-connector module is excluded. If I am assuming your POV wrongly, please tell me what you are looking for otherwise.

Additionally, right now the documentation seems to do a really good job of mixing axon 4 and axon 5, which is hard to understand. It looks like axon 5 is 100% backwards incompatible. I’m in a state of trying to learn something and the documentation contradicts itself. General internet won’t have valid documentation (thus breaking AI too) because it’s all out of date. So I’m frustrated and finding myself in a … well this doesn’t seem to be the right tool scenario.

From the documentation perspective, please bare with us; again, there are a ton of moving parts with what we’re maintaining, so I can imagine some documentation is lacking behind. Whenever you find any incorrect parts, feel free to file concerns about that on the forum, draft a documentation issue with the Framework repo, or provide a pull request even. The documentation should all be situated here. So, thanks a ton for these pointers. It just shows there’s more effort on our end to improve things.

Know we are aware of this, and that we are doing our utmost to improve everything that’s provided

10

Quick update: I am guessing you may be referring to this dependency in Axon’s Spring Boot Autoconfiguration pom.xml? If right, that’s a great catch actually. IMO, making that optional does not make it so that AF’s default towards Axon Server is removed. But it does make it so that the choice exists again, as was the case with AF4.

11

Yes, I’m aware that I’m part of the problem.

Yes, that is exactly what I am referring to; it should be optional and provided (although I’m not sure how gradle deals with those scopes), and the “test starter” should not depend on axon-connector either. I have mixed feelings on the regular starter, it’s likely that people will depend on the main starter and would trigger this if it’s there. It might be better just to tell people to depend on axon-connector directly.

I’m not certain what you thought I meant. I think you were trying to solve the … political/finance problem that exists in the “open source” world. Which is different from this very technical issue.

1 Like
12

My fault here for sure! I misread your reply as a request to remove Axon Server as a default throughout Axon Framework. While, looking back, you were specifically talking it being optional. Is just glanced over your reply to quickly there, @xenoterracide. My apologies again there :folded_hands:

Awesome, thanks for the confirmation. I made a PR right away (found here) that makes the axon-server-connector an optional dependency for the axon-spring-boot-autoconfigure. Slated it for 5.1.0 (which is planed for end of Q1 2026).

Just to make sure I follow your point of view: is making it optional sufficient in your opinion, or is there some addendum we can do to make things more flexible?