search

pact-foundation / pact-jvm

JVM version of Pact. Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project.
https://docs.pact.io
Apache License 2.0
1.07k stars 475 forks source link

AVRO support for pact-jvm #603

Closed gammabowl closed 6 years ago

gammabowl commented 6 years ago

As seen here in this example for kafka pact test (https://github.com/DiUS/pact-jvm/blob/master/pact-jvm-provider-gradle/README.md#verifying-a-message-provider-version-2212) - Is it possible to add AVRO support for the PACT library ? I didn't find any existing issue around discussion about avro support, so wondering to know thoughts about it.

uglyog commented 6 years ago

It is still undecided whether it is necessary to do contract tests with protocols like AVRO or protocol buffers, as the schema is embedded in the payloads. You just need to verify that your code conforms to to the schema.

At the moment there is no plan to support these protocols, apart from Thrift which is JSON based.

gammabowl commented 6 years ago

@uglyog - thanks for the clarification. Will close the issue for now.

gayatreemishra commented 3 years ago

@uglyog - Is it possible to add AVRO support for the PACT library ?

We are looking for this solution as our microservices are event based which is using avro schemas while communicating via Kafka message bus. Where as the current solution available is only supports json which does not seems to be appropriate from contract validation when the provider message is of the avro format. As the Avro takes care of schema changes and validation of the messages, could you please help us understand what is the benefit that we can get from using pact contract testing for validating events.

uglyog commented 3 years ago

@mefellows one for you

mefellows commented 3 years ago

I don't know Avro as well as something like protocol buffers w\ gRPC, so I'll have to come back with more detailed information.

But, one thing is for sure with any of these self-describing technologies that allows old programs to read new data and new programs to read old data; they can't magically fix bugs with what your programs want to do with the data.

Put another way. Let's say a message has the field price in the message for an Order event. Let's say you have a consumer that reads these messages and tallies up the total amount of orders in $$ for a given time period. If you can remove price from the message and have the programs still communicate, that's nice, but the application is still very much interested in price, so you will still have a problem.

You can use tools like the Kafka schema registry to catch this class of bug, or do schema comparisons (see this blog series just released: https://pactflow.io/blog/contract-testing-using-json-schemas-and-open-api-part-1/) to get you some of the way. Just note that the schema registry will only pick up bugs once your change has been committed, built, tested and released into a test environment (where the test schema registry matches exactly the evolution of prod).

Contract-testing aims to catch those class of bugs.

mefellows commented 2 years ago

Just following up on this. Work on our plugin architecture has just begun, you can follow progress on the roadmap here.

Plugins is how we intend to support technologies such as Avro, and our first set of plugins will be for gRPC and Protobufs.

You can register for the Pactflow developer preview program for updates and early briefings / demos as we work through it.