Anyone using Pact or Consumer driven contract testing and Axon?

Imported from Google Groups
1

I asked a question in SO about Pact and Axon and I’d like your input, please.

https://stackoverflow.com/questions/62392004/any-problems-when-using-pact-for-async-messages-that-are-commands-or-queries-ins

I copy and paste the question here:

2

Hi,

I have some example (Axon Framework - Spring Boot) of using Pact to test message (commands, events) passing contracts https://github.com/idugalic/axon-contract-testing-demo

Please note that this is a demo. In the real world, you should consider using Pact Broker instead of sharing contracts in the pacts folder, and integrating the Pact broker into your CI.

Best,

Ivan

3

Hi,
thanks for your response. I’m actually aware of your repo and I’ve used it as a guide. Thanks a lot for that.

But what would happen if we wanted to test query handlers using Pact? Queries in Axon have requests a responses, right? So we’d need to create 2 different interactions in Pact, wouldn’t we? That wouldn’t be the case if we were using HTTP instead of async messages.

What are your thoughts about that?

4

Hi,

Yes, queries have the notion of request and response. I would go with the design you have already mentioned, and maybe have two PactVerifyProvider-s . One for the request (similar to how you test the commands) and the other for a response (similar to how you test the events). Please note that Axon Framework does not provide Test Fixture for the query side at the moment, and you would need to create a regular Spring Boot or some other type of unit-integration test from scratch, and then extend it with Pact.

I did not find the time to implement this in the demo application, but it is on the list :slight_smile:

Best,
Ivan

5

Hi Ivan, I’ve been learning more about Pact in the last few days. I’ve learned about CI and CD workflows, tagging and webhooks.
I believe that having all the checks and validations like using the can-i-deploy tool as Pact’s team recommend here https://docs.pactflow.io/docs/workshops/ci-cd/ would block us merging or deploying when we try to contract test a Saga or a Query Handler. In those two cases, Service A and Service B would have a circular dependency, for example:

Service A is interested on some data that Service B exposes.
Service B has a QueryHandler method that receives GetDocument messages and returns Document messages.
Service A is the consumer of the Document message and the provider of the GetDocument message.
Service B is the consumer of the GetDocument message and the provider of the Document message.
Service A and B are in a circular cycle.
Service A can’t deploy because the contract for Document is not verified.
Service B can’t deploy because the contract for GetDocument is not verified.

Do you have any thoughts on how to handle these cycles or any thoughts on those checks done by CI/CD pipelines?
Thanks a lot!

6

Hi,

In my opinion, mutually dependent services should be avoided. If you are in this situation than you are most probably in the Partnership relationship across the teams that produce these services. This implies that it will be hard to do the independent deployment of these services in general. In this case, the teams are very close to each other and contract testing is not that much needed in the first place. So, there is a reason why it is hard to implement CD for this case.

I also believe that by using three types of messages smartly (Commands, Events, Queries - that Axon provides at the moment) you can fix this mutual dependency, and make it upstream-downstream (only A-downstream depends on B-upstream). For example, rather than B subscribing/querying the A, A can send a command to B. This is a much better design and it would enable independent deployment of these services to some extent.

Best,
Ivan

7

I understand, but how can that be avoided when using a Query message? As soon as I use a QueryHandler, I’ll have 2 services in a cycle from a Pact point of view.