Hello I have couple of naive questions regarding P...
# pactflow
k
Hello I have couple of naive questions regarding Pact and PactFlow • For PactFlow ◦ I see graphql support for PactFlow is on plan, may I know what is the status, is it under development? ◦ In Bi-directional contract testing, is it expected that OAS is already verified using functional test against the provider before publishing? • For Pact ◦ Is the Pact only intended contract testing or also for the data checking? ◦ If it's also for data, how do you guys to manage the mock the right data in easy way? Based on developer feedback, people felt it takes some time for writing the tests with mock data to generate the pact files I hope this is the right place to ask these questions, if not, point me to the right channel 🙂
b
> In Bi-directional contract testing, is it expected that OAS is already verified using functional test against the provider before publishing? It's a good idea, definitely. Don't want to publish a contract for a broken provider implementation. That's also why you can / have to upload additional provider test results with your contract. That said, those test results aren't parsed or used (at the moment), so technically they can contain bogus information. > Is the Pact only intended contract testing or also for the data checking? You could use it to test the implementation of the provider (does it return the right data?), but people tend to highly recommend not doing that. There are more efficient ways to test the implementation of your provider (using tools like Postman or libraries like REST Assured for example). Contract testing is a means of verifying that consumer and provider don't have potential integration issues, not to test provider implementation. > If it's also for data, how do you guys to manage the mock the right data in easy way? Even though you don't need to pass a lot of data from consumer to provider, you might need some (i.e. '_Please make sure resource ABC exists before your verify this interaction_'). The provider state (especially when using arguments) are a good way to do this. I don't know about the status of GraphQL support.
💯 1
m
• I see graphql support for PactFlow is on plan, may I know what is the status, is it under development?
This is still something we are considering, but there are no active plans at this stage Kishore
✅ 1
k
Thank you for your answers @Bas Dijkstra
Contract testing is a means of verifying that consumer and provider don't have potential integration issues, not to test provider implementation.
Regarding this point, the open source version of pact actually does replay your consumer pact against provider right? Our tests usually fail due to data mismatch between expected and actual response from the provider. Is there a way to test only the contract, but not the data? May I missing some CLI param while running on the provider side.
@Matt (pactflow.io / pact-js / pact-go) Thank you Matt, we have few core backend services running on GraphQL, I'm trying to check feasibility of bi-directional contract testing for that.
👍 1
m
Regarding this point, the open source version of pact actually does replay your consumer pact against provider right? Our tests usually fail due to data mismatch between expected and actual response from the provider. Is there a way to test only the contract, but not the data? May I missing some CLI param while running on the provider side.
Yes, you should use matchers.
k
Ah, so this is what the example app uses in the pactFlow. @Matt (pactflow.io / pact-js / pact-go) Correct me if my understanding is right, the default settings of pactFlow is using only matchers, not checking the data, but I believe there would be option to check along with data without matchers as well.
m
Sort of. PactFlow is just the place the contracts are uploaded to, it doesn’t do any testing in and of itself. Pact is where you set (or don’t set) matchers The examples seeded to PactFlow use matchers though, yes, as this is the standard way you’d test most APIs
✅ 1