Will Pact work with AMQP?

[Adam Satterfield]

Hi-

We are using RabbitMQ as our message bus and I was curious if we could still use Pact being that Rabbit uses the AMQP message protocol.

Thanks!

[Ronald Holshausen]

Hi Adam,

As far as I'm aware, Pact only supports HTTP. But I have been thinking about how to do consumer driven contract testing with message queues (I'm working on a project that is going to use Apache Kafka). I feel it is even more important with message queues, because you need to know what consumers of a message you could break when you change a message structure that you produce and there is no direct link as to who is consuming the message.

I'm leaning towards treating the message queue as the transport, and have a way of producing a message and then running the consumer tests against it. It way be done without having to implement the actual message queue protocol, maybe by mocking out the call to the message queue and persisting the message.

--
You received this message because you are subscribed to the Google Groups "Pact" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pact-support...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Ronald Holshausen

DiUS Computing Pty Ltd

Level 10, 99 Queens Street
Melbourne, VIC 3000

Phone: +61 3 9008 5400
Mobile: +61 413 162 439

http://www.diuscomputing.com.au

[Bethany Skurrie]

Hi Adam,

I have been using the Pact matching portion of the pact library to create and verify contracts for non-HTTP services on my current project, and it works quite well. As there is no neat HTTP layer to inject the tests the way that normal Pact does, you as the developer need to work out where to put the appropriate tests - one that shows that the consumer can handle the message(s) that you expect, and one that shows that the provider actually creates the expected message(s). The two tests are kept in line via a contract that is shared between the two projects, just the way a Pact is.

Cheers,

Beth

Bethany Skurrie
Software Developer

DiUS Computing Pty. Ltd.
where ideas are engineered

Phone: +61 3 9008 5400

Mobile: +61 415 413 713

www.dius.com.au

This email is intended solely for the use of the addressee and may contain information that is confidential or privileged. If you receive this email in error please notify the sender and delete the email immediately.

[Adam Satterfield]

Hey Bethany-

Thanks for the great reply!  Do you have a Git or other documentation you can point us to for the non-HTTP contract verification?  

Ronald, thanks for the info!

[Bethany Skurrie]

Hi Adam,

Here is a gist: https://gist.github.com/bethesque/0ee446a9f93db4dd0697

Beth

[Adam Satterfield]

Thanks Beth!

Very helpful!

[Justin Fields]

Hey Beth, I'm actually the developer who is trying to implement the PACT algorithm with Adam. I looked at the Ruby code you posted, and maybe it's because I'm just not a Ruby person but it seemed like it was still using HTTP. Could you explain what you did by any chance just so I might have a better idea for how to apply it to our java rabbitmq application. 

I'm using https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-consumer-junit for the consumer end, and https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-provider-gradle for the producer end.

[Bethany Skurrie]

Hi Justin,

The HTTP code that is in there is specifically for publishing the contract to the pact broker, nothing to do with the execution of the tests.

In both the JVM and Ruby versions, when you declare the request and response using the Pact DSL, ("uponReceiving" and "willRespondWith") you're building a structure that has two purposes - 1. it provides the concrete example request and response used in the tests, and 2. defines how to validate the the actual request/response against the expected request/response. The two different uses of this structure 

The file expected_data_from_collector.rb declares an object graph using the Pact DSL. This is going to be used to create the concrete example and the contract. This could be declared inline, but for easier maintenance, and to allow the contract publishing code to easily access it, it's in a separate file.

The file consumer.rb takes that object graph declared in expected_data_from_collector.rb, and generates an example JSON document from it (that's what FixtureHelpers.load_generated_pact_fixture does). It then uses that JSON document in a test to show that it can handle the document we expect.

The file consumer_publish_contract.rb shows how we take that same object graph and turn it into the JSON Pact-like contract, and publish it to the pact broker.

The file fixture_helpers.rb shows the code that is used to turn the object graph declared using the Pact DSL into the example structure.

The file z_provider.rb contains a test that uses the contract that we retrieve from the pact broker. It shows that the output that we produce contains all the data that the consumer expects (of course, it may contain extra data without it being a problem).

Hope this clarifies the code a bit better, I know that reading an example in a language that you don't use much is not terribly helpful! Let me know if you have further questions.

Cheers,

Beth

--
You received this message because you are subscribed to the Google Groups "Pact" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pact-support...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bethany Skurrie]

Sorry, realised I left a sentence half finished.

"The two different uses of this structure are hidden from you when using HTTP Pact because the mock service handles number 1 in the consumer tests, and the verification task handles number 2 for you in the provider tests. When using Pact in a non-HTTP scenario, there is no nice neat protocol layer to do this for you, so you have to explicitly do each step."

[Justin Fields]

Thanks Beth! Really appreciate the response and input. Definitely helped a lot!