https://pact.io logo
Join Slack
Powered by
Hello I'm trying to implement a pact solution for ...
# general
c
Hello I'm trying to implement a pact solution for the multiple dependent microservices scenario A -> B -> C. The most detailed description of the problem and the potential solutions seems to be the following GitHub Gist: https://gist.github.com/bethesque/43eef1bf47afea4445c8b8bdebf28df0#file-index-md What is meant with the following sentence? "Then, in your Pact test for CClient, you can use the same alligator instance as a "link" to tie your stubbing to an artifact that will get verified." Can someone elaborate a bit more on that? "your Pact test": Which pact test is meant here "AB provider test" or "BC consumer test"? "same alligator instance": Is the same subbing instance to be used in both tests? "AB provider test" and "BC consumer test"? Who writes to the shared artifact and who reads from the shared artifact? Thanks
b
Generally there's no "provider test". There are just consumer tests and provider verifications.
"your Pact test for CClient" would be the test that exercises CClient, and is verified by C API.
But really, you don't typically need to think about AB and BC at the same time. They have separate lifecycles and workflows and pipelines.
c
I would like to learn how to implement either of the approaches. The one where I would not look at AB and BC at the same time, which you refer to and the one where I would look at them at the same time. Once I would understand both approaches and how to implement them, I could still choose the more typical solution, you are referring to. But knowing both approaches would give me a bit more feeling of control over the whole thing, which I'm kind of lacking currently 😊 But do I understand it correctly, in the more typical approach you are referring to, I would have to set the "AB provider verification" boundary at B API or B Controller yes? I mean I would have to mock any calls towards the inner parts of B Codebase and set the state of B at B API or B Controller boundary yes?
By the way, how do typical pipelines for B look like? Do my pipelines look valid/typical? B provider pipeline: -         Test CClient -         Test B-API or B-Controller -         Publish BC pact -         Can-i-deploy -         Deploy B verify changed AB pact pipeline: -         Test CClient -         Test B-API or B-Controller
b
There are a bunch of diagrams in the docs (https://docs.pact.io/pact_nirvana/step_4/#consumer-pipeline), about pipelines 🙂 the specifics will always depend on what your situation looks like, but the high level is generally consistent
There's not really an approach where you'd look at AB and BC at the same time. The intent is to isolate those interaction points so you can run things independently (otherwise you end up back in integrated testing land).
As far as stubbing goes, you get to decide where it makes sense to cut. Depending on your internal architecture you may have different options. I prefer to cut just inside the provider, once requests have been parsed, to make sure they make sense. Other people might not have such a clean internal structure, and choose to stub on the outside, e.g. stubbing entire external dependencies.
c
So if for example in case of A sending 11 to B the valid expected response of B were x,y,z where x & y were independent of C and z were dependent on C, I could basically stub z along x and y yes? And would have the case 11 --> z to be included in the BC-consumer tests or not necessarily?
b
Yep, that sounds right to me 🙂 The z binding through to C can be tested in a separate runtime/lifecycle, and should be from the perspective of B making a request to C (independent of the AB request). If you break up the coupling that way, it could be any data, not strictly 11->z (which would be a required data coupling if run in the context of the AB request).
Open in Slack
PreviousNext
Powered by