https://pact.io logo
Join Slack
Powered by
So, I came here from <https://docs.pact.io/faq/con...
# general
b
So, I came here from https://docs.pact.io/faq/convinceme .. I am still yet not convinced, because of our current workflow is 180deg different on what pact offer that is Consumer-Driven. But "I have control over the consumer", this mostly internal apps afterall. so 1. Will consumer now dictate the provider endpoint and response ? 2. Then each of my consumer now will write basically some 80% identical tests because most of them require the same response from the same endpoint ?
t
You don’t have to have the consumer design the provider endpoints. Consumer driven design is different to consumer driven testing.
Consumer driven testing exists because that way you’re testing the parts the consumer is ACTUALLY using, and not anything else
(Side point: Consumer driven design is less common than provider driven design, but I don’t think there’s a good reason for this. After all, who is the provider for? Surely it should provide what the consumer needs, not provide what it thinks the consumer needs)
Then each of my consumer now will write basically some 80% identical tests because most of them require the same response from the same endpoint ?
Do they really require the same response? Usually different consumers want different parts of the response from the same endpoint. Without Pact, testing this will still have some duplication. It might indicate that there’s a client library that’s worth splitting out or something.
b
You don’t have to have the consumer design the provider endpoints. Consumer driven design is different to consumer driven testing.
Oh, so I could use pact to verify the interaction after the spec is laid out ?, so is this an acceptable flow ? 1. provider design first, output via openapi spec 2. consumer view the spec, write the test for their expected response 3. provider then write their own side of pact
✅ 1
Without Pact, testing this will still have some duplication. It might indicate that there’s a client library that’s worth splitting out or something.
Hmm, I agree
t
Yes, except that you might be confused, depending on what you meant by step 3 - the provider doesn’t write a pact file, they write a test that verifies the consumer(s) pacts.
☝️ 1
A subtlety here is that the openapi spec and the contract file have different purposes. The spec describes the grammar of the requests and responses (useful for implementers), while the contract describes several example request/response pairs in different server states (useful for testing).
b
they write a test that verifies the consumer(s) pacts.
Oh sorry, yes I mean this
t
You can’t actually take an openapi spec and generate a pact file, and you also can’t take a pact file and generate an openapi spec - even though at first glance it feels like you should be able to.
b
So what I meant is that consumer can have some guidelines to write the pact, and not burden them with designing the api
t
They’re different.
Yes, that’s right
A consumer driven testing approach doesn’t force you in to a consumer driven design.
(I personally believe the best practice would be consumer driven design, but a lot of teams don’t want to work that way, for various reasons)
b
A consumer driven testing approach doesn’t force you in to a consumer driven design.
This is maybe what I miss when I read how the pact works
t
Right, yeah
b
I think its more clearer now
Thanks a lot
t
You’re welcome! By the way, I’m working on another tool which lets you write the contract at either end, if you want to do server driven contracts. It’s not at a stable release yet, but you can follow the progress here https://case.contract-testing.io/docs/intro
I would also say that:
because of our current workflow is 180deg different on what pact offer that is Consumer-Driven.
This is definitely the most common way to design APIs at the moment, and I’ve worked with teams who are thinking and working this way to successfully use Pact without changing the way they work.
👍 2
Open in Slack
PreviousNext
Powered by