Hello I'm trying to implement the A->B->C scenario using the suggestion here: https://gist.github.com/bethesque/43eef1bf47afea4445c8b8bdebf28df0#file-index-md I would like to implement the solution 1 involving "shared artifacts or fixtures" to tie upstream and downstream pacts together. But I'm not sure how this "tying" of pacts can be achieved? Is there any code example or workshop where this method is used? Any ideas, hints? Thanks

I started on an example in python but it needed more work, the gist of it was making sure that all of the responses you stub as responses from B to A get used as the request from B to C to make sure they tie up. Someone else was also having a look and I think nearly had some shareable examples 🤔 (python again)

Is this example "abc" the one you are referring to? https://github.com/pact-foundation/pact-python/tree/fafb3edb52cf589dc1f2f6e752df5e25e3fd4b53/examples#abc

Yeah, so the conclusion from that one was it's probably too tightly coupled, because it's going down to the http level rather than higher up

But the overall concept of tying pacts and using shared artifacts/fixtures would be still valid yes?

I believe so, yes (disclaimer: not a maintainer). The discussion was over here that we were having about it, might be helpful: https://pact-foundation.slack.com/archives/C9VECUP6E/p1637360662056400?thread_ts=1637360662.056400&cid=C9VECUP6E

Thank you very much, I have to go through that discussion. Is the usage of shared artifacts/fixtures with these python example(s) the same usage as described here for ruby: https://app.slack.com/client/T5F60FXSQ/search/search-5a77dc0f-9b22-4ce3-af37-b49ebf47ae73/thread/C5F4KFKR8-1556263639.004900?cdn_fallback=1 "Beth (pactflow.io/Pact Broker/pact-ruby) In the ruby code, you can create a pact request or response object outside of the dsl that is used to set up the mock. You make a fixture (not sure if the same term is used in python). Then, you use the same fixture to generate the downstream pact, and response to the upstream pact." So, on the A-B-provider side, you mock the downstream calls and then with the help of some pact method you can create an object, store that as shared artifact/fixture and then on the B-C-consumer side you use that shared object to create a matching/tied pact?

I think so yes, the question has been going on for some time it seems! There was some good input from Tim on where the Pact part should wrap around (which was where the python example needs to be changed to follow instead of the low level http). I liked the idea of those fixtures working at a higher level because then the same pattern works regardless of if you're using http or, somewhere A-B-C becomes even more relevant: message!

To be sure whether I understand you correctly, let's consider the following example: Let's assume that if A would send 11 to B that B would have to return with x, y & z, where x and y were independent of C but z were dependent on C. I could manage x and y by setting the state of B. During the setting of the state of B I could prepare an entry 11 --> x, y in a lookup list or something. So the x and y part of the expected response would be cared for. Then I would have to stub CClient (the part of B which is calling C API) in such a way, that if it received 11 it would have to return z yes? And then someone would also have to make sure that the case 11 --> z would be included in the BC-consumer tests where the real CClient is being tested yes? But what is the role of the shared artifact here? Which information is in the artifact? The information 11 --> z ? For whom? For the stubbed CClient during AB-provider-verification or for the BC-consumer tests of the real CClient?