heytaco
2020-08-25 03:57
Hi there! My name is HeyTaco!, and you can use me to give people tacos to show your appreciation. My tacos will spread joy through Slack!
matt.fellows
2020-08-31 22:26
I know Federation is different but is there a specific part that's causing issues?
p0deje
2020-08-31 22:28
We used to have 2 contracts between:
1. _Frontend_ and _Service A_
2. _Frontend_ and _Service B_
Now the communication happens through the federation gateway so in fact the contracts are:
1. _Frontend_ and _Gateway_
2. _Gateway_ and _Service A_
3. _Gateway_ and _Service B_
p0deje
2020-08-31 22:29
But the federation is simply a proxy, so it?s impossible to simply verify the contract on its side (without actually sending all the requests to the underlying federated services)
p0deje
2020-08-31 22:46
Well, not always a proxy. It also stitches multiple GraphQL schemas into a single one so consumer can make 1 request, gateway will turn this into 2 requests to services A, B, then join the response and return it to the consumer
p0deje
2020-08-31 22:47
In this case it has a logic for delegating requests to the underlying services and joining responses, but that?s about it
p0deje
2020-08-31 22:48
This makes it impossible to use provider states because consumer knows only about federation gateway
p0deje
2020-09-01 11:46
hey @matt.fellows, sorry to bother, but have you had a chance to think about that?
matt.fellows
2020-09-02 00:31
So Alex, I think you really only have 3 options at the moment.
1. Have the federation layer stub out any external services (which is probably all of them). This is less than ideal if all it does is aggregate the results of two other services into a single resource, but there may be tools on offer that can easily create stubs based on types
2. Include the federation layer in the provider side verification. Less than ideal, because this will naturally be more of an integration-style test and won?t scale with teams + services
3. Use a schema contract testing approach - basically compare the GraphQL schemas between the _Frontend_ and _Gateway_ and check that the schemas are compatible (I haven?t tried, but tools such as https://github.com/fabsrc/graphql-schema-diff could be the key). You could then use standard Pact tests between the _Gateway_ and _Service A_/_B._
I?m literally about to release a blog about this sort of thing (3), and you can read the draft here https://pactflow.io/p/31fc798c-1a8b-4796-b706-419a481ec4de/.
There are a few assumptions built into this, as well as a bit of ignorance as I?ve never used schema stitching/federation before. I have a conceptual understanding of it, but there are likely areas I?m ignoring that may lead to better solutions
p0deje
2020-09-02 00:52
We actually had another idea where, the contract will be auto-generated on the gateway verification side:
1. _Front_ creates consumer test for _Front-Gateway_ contract.
2. _Gateway_ implements a custom Pact verification job which splits _Front-Gateway_ contract into 2 separate contracts for _Gateway-Service A_ and _Gateway-Service B,_ publishes them to the broker and runs `can-i-deploy`. The latter controls the success/failure of the verification job.
3. _Service A/B_ act like normal providers with regular Pact verification.
This way our Pact setup matches the implicit multi-contract federation. Do you believe this is something that makes sense and is doable with Pact?
matt.fellows
2020-09-02 00:58
Interesting. It could work. It?s kind of a variant of (3) where you?re using the pact contract as a schema (because you?re not validating behaviour directly, but creating separate sub-contracts for verification). But then running the actual verification
p0deje
2020-09-02 01:07
Is it possible to customize the verification job (we use pact-ruby) to that extent: generate new contracts, publish them, run can-i-deploy (or check matrix directly)?
p0deje
2020-09-02 01:12
Though one of the nicest parts of verification - diff of expected and actual response is definitely going to be lost in this case.
matt.fellows
2020-09-02 11:19
Worst case, all of the APIs to the broker are there and you could fall back to those
matt.fellows
2020-09-02 11:19
How would your federation layer know where/how to cut the `frontend` contract to its constituent parts?
p0deje
2020-09-02 11:34
The same way it knows how cut single request into multiple ones - based on schemas from downstream services
matt.fellows
2020-09-02 11:38
that will only work for when the integration is ?up and running?. When a frontend updates a contract to ask for some new property field `A` - what will you do?
matt.fellows
2020-09-02 11:38
or put another way, it will be hard to enable the consumer-driven flow here
matt.fellows
2020-09-02 11:39
but also appreciate that we are working around the tooling a little, so that?s probably a trade off you?re willing to accept
p0deje
2020-09-02 11:51
We?re in the process of starting to use it and we have some contract tests which will break
matt.fellows
2020-09-02 11:51
I can see why you wouldn?t. It?s like testing a router like nginx (albeit, I have done this :stuck_out_tongue: )
p0deje
2020-09-02 11:52
> that will only work for when the integration is ?up and running?
I think that it can do this statically. I?d assume it doesn?t need to fetch schemas from live services.
matt.fellows
2020-09-02 11:53
what I mean is that it will only work once you have a stable set of tests
matt.fellows
2020-09-02 11:53
i.e. the consumer, federation layer, and downstream APIs are working and compatible
matt.fellows
2020-09-02 11:53
but now say the frontend adds a new field (field `z`) that doesn?t exist yet - what will you do?
matt.fellows
2020-09-02 11:54
(and yes - definitely _not_ suggesting you hit real services to extract schemas, Pact is kinda?against that :slightly_smiling_face: )
p0deje
2020-09-02 11:58
If consumer needs new field `A` it would:
1. create a consumer test for `Gateway` that asks for it
2. publish new contract
3. CI would trigger `Gateway` verification that would fail because no downstream schemas have `A`
4. provider would implement `A` and deploy
5. `Gateway` verification would now generate a new contract with `A` to `Provider` (because it has new schema)
6. publish new contract
7. CI would trigger `Provider` verification
8. `Gateway` verification will `can-i-deploy` to ensure that current `prod` versions of `Gateway-Provider` are compatible
9. finally, consumer gets green build
matt.fellows
2020-09-02 11:59
It?s more the point that the failure at (3) (and wherever you fail the consumer build on the `can-i-deploy`) that you won?t get explicit feedback why it failed - they should have an idea of course
p0deje
2020-09-02 12:50
> It?s more the point that the failure at (3) (and wherever you fail the consumer build on the `can-i-deploy`) that you won?t get explicit feedback why it failed - they should have an idea of course
Yeah, that might be super annoying.
p0deje
2020-09-02 12:50
We?re not even started yet and we have other ideas on the table (including stubbed our services or just dropping contract tests and relying on schema diff)
matt.fellows
2020-09-03 00:57
I think your strategy is a good starting point, otherwise falling back to schema diffing would be the next most preferable.
matt.fellows
2020-09-03 00:58
I guess you?ll have to feel it out a bit further. My guess is that the trade-off you get vs the benefit would be worth it (
uladzislau_danilchyk
2020-10-29 13:22
Hi everyone! I have a question regarding creating pact tests for React app which uses GraphQL and Next.JS.
I have functional component for rendering product details, e.g. `const productDetails: NextPage<IProps> = () => { ... }`
Inside that component I'm using the following query:
``` const { data, error } = useQuery<ProductDetailsQuery>(productDetailsQuery, {
variables: {...}
});```
But this code is placed in middle of the functional component and I don't understand how to cover such example with test.
Could you help me please?
uladzislau_danilchyk
2020-10-29 13:25
In examples I have seen some service which calls ApolloClient and so on. But in our case we're using useQuery() inside a functional component
matt.fellows
2020-10-29 22:56
you really need to extract out the API calls from your react component into a separate interface - they are too coupled at the moment and you can?t test them separately
uladzislau_danilchyk
2020-11-04 13:27
Hi guys! What is the difference between `ApolloGraphQLInteraction` and `GraphQLInteraction`?
uladzislau_danilchyk
2020-11-13 10:44
Hi everyone! I use GraphQL together with Pact.
I have two types of Labels:
```interface Label {
key: String!
value: String!
}
type LabelOne implements Label {
key: String!
value: String!
}
type LabelTwo implements Label {
key: String!
value: String!
endDate: String // <----
}```
The usage of it in schema is like: `type Device { labels: [Label!]! }`
In consumer test I have a query like:
```...
labels {
key
value
... on LabelTwo {
endDate
__typename
}
__typename
}
...```
My question is: How to write a response expectations that tell me that response for labels should consist of two structures?
matt.fellows
2020-11-17 06:50
Hi @uladzislau_danilchyk sorry you caught everyone over the weekend it seems :slightly_smiling_face:
matt.fellows
2020-11-17 06:58
Is your question more than some elements of `Label` will have `endDate` and some won?t?
sagupta
2020-12-09 17:11
Hello ,
Is it worth setting up contract tests between graphql resolvers to APIs ?
sagupta
2020-12-11 09:17
The thing that I am not sure about is :
? How to decide scenarios on what end points to cover or cover all because front end will send queries to graphql which can change and based on what is there in queries, resolvers would call the APIs
? So that means we need to cover all paths
matt.fellows
2020-12-11 11:13
My suggestion: from a data point of view, test examples where most/all of of the properties are there, and then a separate test with a minimal request/response
matt.fellows
2020-12-11 11:14
then do the usual sets of tests to cover various response codes - `400`, `404`, `201` etc.
sagupta
2020-12-11 11:18
So should this approach be applied to all end points like
/a/company- GET/POST/PUT
/a/user-GET
/b -POST
If I take 5 tests for each,then I have a lot of test already
matt.fellows
2020-12-12 01:25
You need to write enough tests that cover the various independent / unique set of expected interactions
matt.fellows
2020-12-12 01:27
There are some tips on the docs on writing effective consumer tests. But don't try to cover all data values, it's really the request/response shapes were interested in
writetojoshma
2020-12-20 03:12
This sounds amazing...Even I am looking for a similar approach...Can I pls know how your pact looks like between gateway and backend...I am so confused here..How does your backend understands the graphQl "Query" in the Pact(Json)
matt.fellows
2020-12-20 23:50
So between your GraphQL layer and backend RESTful endpoints is just ?normal? Pact.
matt.fellows
2020-12-20 23:50
If you?re not across how that works, here is a short tutorial you can do to get an idea: https://docs.pactflow.io/docs/tutorials
writetojoshma
2020-12-21 11:09
If I need multiple pacts between same consumer provider set , hows the approach
writetojoshma
2020-12-21 11:15
I think there will be only one pact between a consumer and provider as long as the consumer requirements changes
matt.fellows
2020-12-22 00:27
1 pact contains all of the interactions between a given consumer and provider
matt.fellows
2020-12-22 00:28
> So its ideal to have different files for different consumers
test files or pacts?
test files - up to you
pacts - no, just one pact per consumer/provider pair
matt.fellows
2020-12-22 10:36
All of the docs for pact js are here: https://github.com/pact-foundation/pact-js/
matt.fellows
2020-12-22 10:36
There is also https://docs.pactflow.io/docs/examples where we have full examples for multiple languages etc.
writetojoshma
2020-12-22 10:38
So technically there should be different pact for Canada-mobile client and Canada-desktop client....also different across markets.....as the consumers must be using different attributes
writetojoshma
2020-12-23 13:12
Can anyone please suggest the approach/scope/interactions of graphql testing --any example
writetojoshma
2021-01-13 10:26
How to test a non mandatory field in graphql using pact....how can I test if a field can be null or non empty in a single contract ??
matt.fellows
2021-01-13 10:35
:point_right: I think you?ve already asked this: https://pact-foundation.slack.com/archives/C9VBGLUM9/p1610111230153300
writetojoshma
2021-01-13 11:23
Yes right , so I will have to use a non pact tests for such scenarios if requirement says the field is not mandatory
matt.fellows
2021-01-13 12:51
No, that's not what we said. You'll need to have test for when they're present and not present
writetojoshma
2021-01-13 13:00
Okay , but if I Have a case when I dont know what provider will respond with a null or non empty....then when provider sends a null , my non empty interaction will fail and vice versa....is my understanding correct.
matt.fellows
2021-01-13 23:44
yes, but the point of Pact is that you can have control over the scenarios in which they should be null, empty or populated
matt.fellows
2021-01-27 11:32
I haven?t seen it done before. Pact is _consumer driven_ by nature, but we?re currently experimenting with a more collaborative version at Pactflow now. I don?t think it will work for your current case yet, because we are starting with OAS3.0 (not graphql).
matt.fellows
2021-01-27 11:33
It would be possible with some extra work with what we?re planning though
matt.fellows
2021-02-02 10:42
@denitsa.kulezich are you about to briefly chat about https://github.com/pact-foundation/pact-js/issues/592?
matt.fellows
2021-02-02 21:47
Could you please upload your code to the gh issue so that I can diagnose further? Without having real code, it?s going to be hard to diagnose
matt.fellows
2021-03-09 02:52
@ben.kirberger so I?ve found an old conversation about GraphQL apollo testing. It?s not visible in slack, because free tier limits
matt.fellows
2021-03-09 02:52
I?ve just dumped an HTML version here: https://docs.pact.io/slack/graphql.html
matt.fellows
2021-03-09 02:52
Look for `p0deje` posts / ?federation?, and see if the suggestions are helpful
rafael.anachoreta
2021-05-11 15:31
~Hey all, is there any way to test a mutation that uses file upload (`multipart/form-data`) with GraphQL at the moment?~
Edit: I suppose that wouldn?t be really ?graphql? anymore but rather a middleware
sreid
2021-06-16 23:50
Here's an example of using Apollo with mutations. there is also a https://pact-foundation.slack.com/archives/C01BVFCMMK9/p1623820327000900 making its way into the repo.
_this example was retrofit from code. fundamentals should all be there_
dalkire
2021-09-21 15:50
Hi all, I?m curious if there is any documentation on testing Interface Types. All I have seen are straightforward examples with fields of primitive types. Is there a way to test a query that returns an array of multiple possible types? For example you have a homepage that can show product cards (image, title, price, etc.) or promotional cards (image, cta, etc.). The idea being that the homepage knows how to display whatever data it receives as long as it conforms to the interface and is one of the accepted types. Is that testable with Pact?
matt.fellows
2021-09-22 00:44
Not that I?m aware of, but if I understand correctly an interface type just describes the primitives common to each of the concrete types? If that?s the case, I don?t see why it wouldn?t work
caiquedpfc
2022-02-01 13:33
Hello everyone, how are you? I?m trying to make an implementation in a javascript consumer who consumes from a GraphQL API, but I?m getting an error between the queries in the mock and in the client request, but I can?t understand why I?m getting this erros, could someone please help me?
`Actual interactions do not match expected interactions for mock MockService`
``` Description of differences
--------------------------------------
* Expected a String matching /query\s*loadNewShowCase\(\$filter:\s*ShowCaseFilter\)\s*\{\s*loadNewShowCase\(filter:\s*\$filter\)\s*\{\s*messages\s*\{\s*category\s*target\s*key\s*message\s*\}\s*showCase\s*\{\s*images\s*shelves\s*\{\s*id\s*type\s*displayName\s*hasNextItems\s*items\s*\{\s*id\s*type\s*images\s*displayName\s*applicableDiscount\{\s*presentedDiscountValue\s*discountType\s*finalValue\s*\}\s*category\s*\{\s*id\s*displayName\s*\}\s*brand\s*\{\s*id\s*displayName\s*\}\s*price\s*\{\s*min\s*max\s*\}\s*\}\s*\}\s*\}\s*\}\s*\}/ (like "query loadNewShowCase($filter: ShowCaseFilter) { loadNewShowCase(filter: $filter) {\n messages {\n category\n target\n key\n message\n }\n showCase {\n images\n shelves {\n id\n type\n displayName\n hasNextItems\n items {\n id\n type\n images\n displayName\n applicableDiscount{\n presentedDiscountValue\n discountType\n finalValue\n }\n category {\n id\n displayName\n }\n brand {\n id\n displayName\n }\n price {\n min\n max\n }\n }\n }\n }\n }\n}") but got "query loadNewShowCase($filter: ShowCaseFilter) {\n loadNewShowCase(filter: $filter) {\n messages {\n category\n target\n key\n message\n }\n showCase {\n images\n shelves {\n id\n type\n displayName\n hasNextItems\n items {\n id\n type\n images\n displayName\n applicableDiscount {\n presentedDiscountValue\n discountType\n finalValue\n }\n category {\n id\n displayName\n }\n brand {\n id\n displayName\n }\n price {\n min\n max\n }\n }\n }\n }\n }\n}\n" at $.body.query```
I?m putting all my code in the thread bellow
caiquedpfc
2022-02-01 13:36
```import { ApolloGraphQLInteraction } from "@pact-foundation/pact"
import { ApolloClient } from "apollo-boost"
import { createHttpLink } from "apollo-link-http"
import { InMemoryCache } from "apollo-cache-inmemory"
import gql from "graphql-tag"
import * as loadNewShowCaseExpectedResponse from './mocks/loadNewShowCase.json';
import { showCase } from '../../../src/services/api/showcase';
const path = require("path")
const Pact = require("@pact-foundation/pact").Pact
jasmine.DEFAULT_TIMEOUT_INTERVAL = 100000;
const PORT = 20002;
describe("Show Case", () => {
const provider = new Pact({
port: PORT,
log: path.resolve(process.cwd(), "aut-tests/contract/logs", "mockserver-integration.log"),
dir: path.resolve(process.cwd(), "aut-tests/contract/pacts"),
spec: 2,
logLevel: 'DEBUG',
pactfileWriteMode: "overwrite",
consumer: "courier-phoenix",
provider: "ze-catalog-service",
})
beforeAll(() => provider.setup());
afterAll(() => provider.finalize());
describe("Load New Show Case", () => {
beforeEach(() => {
const graphqlQueryInteraction = new ApolloGraphQLInteraction()
.uponReceiving("A request with a new show case")
.withRequest({
path: "/public-api",
method: "POST",
})
.withOperation("loadNewShowCase")
.withQuery(`query loadNewShowCase($filter: ShowCaseFilter) {${showCase}}`)
.withVariables({})
.willRespondWith({
status: 200,
headers: {
"Content-Type": "application/json; charset=utf-8",
},
body: loadNewShowCaseExpectedResponse
});
return provider.addInteraction(graphqlQueryInteraction)
})
test("returns correct body, header and statusCode", async() => {
const client = new ApolloClient({
cache: new InMemoryCache({
addTypename: false
}),
link: createHttpLink({
fetch: require("node-fetch"),
uri: `http://localhost:${PORT}/public-api`,
}),
})
let response = client
.query({
query: gql`query loadNewShowCase($filter: ShowCaseFilter) {
${showCase}
}`
})
response = await response.then((result: any) => {
result.data
expect(result.data).toEqual(loadNewShowCaseExpectedResponse)
})
.catch( error => {
return error
})
})
afterEach(() => provider.verify())
})
})```
caiquedpfc
2022-02-01 13:39
About the showcase variable:
```` loadNewShowCase(filter: $filter) {
messages {
category
target
key
message
}
showCase {
images
shelves {
id
type
displayName
hasNextItems
items {
id
type
images
displayName
applicableDiscount{
presentedDiscountValue
discountType
finalValue
}
category {
id
displayName
}
brand {
id
displayName
}
price {
min
max
}
}
}
}
}
````
caiquedpfc
2022-02-01 14:54
About this error above, I was able to fix the problem by changing my imports to:
```import { ApolloGraphQLInteraction, Matchers, Pact } from '@pact-foundation/pact'
import { ApolloClient, gql, HttpLink, InMemoryCache, NormalizedCacheObject } from '@apollo/client'
import fetch from 'cross-fetch'
import { print } from 'graphql'```
matt.fellows
2022-02-02 00:25
unfortunately, we don?t have first class support for graphql in the DSL, which means we?re forced to do a string regex on the expectation. Some libraries (like Apollo) put extra bits and pieces in the query when the request is sent, which causes issues.
waquino
2022-02-08 14:04
Hi all :slightly_smiling_face:
I had an interesting discussion at my company yesterday and wanted to know your point of view.
A group of developer argued that Pact contact testing doesn?t provide much value when combined with Typescritp/Graphql because with Graphql we can use the schema to generate the type and use those types on our clients to ensure they are in sync with the API.
matt.fellows
2022-02-09 00:48
I?d have a quick read of https://pactflow.io/blog/contract-testing-a-graphql-api/
matt.fellows
2022-02-09 00:49
See also https://pactflow.io/blog/schemas-are-not-contracts/, which talks about how schemas like GraphQL do not provide sufficient contract testing coverage.
matt.fellows
2022-02-09 00:49
There might also be a bit of history if you seach back through this channel
david.uzumaki
2022-03-23 19:48
does the python version have a javascript `withQuery` equivalent for graphql?
(i?m assuming not but thought I?d ask to make sure. otherwise I?ll write my own wrapper for it in my project)
harris
2022-05-25 22:26
has anyone done contract with `graphql mesh`? we have legacy monolith wrapped in graphql mesh(Provider) and consumers are all graphql. I wonder if someone did same way? looking for some opinion / recommendation. Also, has anyone use `ject-apct` package for graphql? it looks like not for graphql now? is there anything work around? the adaptor looks much cleaner/easier to write test. thanks :slightly_smiling_face:
dekkofilms
2022-08-17 22:06
anyone have any experience utilizing the graphql-codegen library to help generate the contracts Pact can use in a mock server? :slightly_smiling_face: been looking at lots of examples and what not, but haven't found anything around in particular with codegen yet.
dekkofilms
2022-08-18 10:34
Well it's generated based on the specific queries/mutations I am making on a certain consumer, and validated locally with our provider of obviously being able to generate its graphql asks based on the consumers definitions. So, there is failure if it asks for things that can't exist based on the provider you have locally.
Obviously a consumer can generate things in a local environment that doesn't exist in a deployed stage. So, I guess I thought since we are generating it?s queries/mutations based on consumer expectations, making those also our pact contracts made sense to me without having to rewrite the expectations.
Now I'll ask cause you got me thinking, any reason I shouldn't be doing it if I'm thinking about this wrong?
dekkofilms
2022-08-29 18:05
Is state handlers something we can't utilize from the GraphQLInteraction?
adding `.given()` does work, but it also creates two interactions for the same test apparently adding the given() call to my interaction. I don't know if having both uponReceiving and given in one interaction is creating those two tests, but based on the type defs of uponReceiving that wouldn't make sense to me.
matt.fellows
2022-08-29 22:17
No it should work exactly the same way (it's just a class over the top of a normal interaction). Are you sure it's creating two interactions for the same test? Can you please share your code and setup?
dekkofilms
2022-08-29 22:25
I?ll show the setup when I get back to my computer. For some reason switching to the ApolloGraphQLInteraction instead of just GraphQLInteraction stopped creating two interactions.
tpaktopsp
2022-09-13 10:11
Wondering what are strategies people using to test Apollo?s `useQuery` hooks with Pact?
The only working one I found so far is to write component tests and that does mean that we are tying pact to our UI implementation. Trying to make pact covered layer as close as possible to the direct http calls.
dekkofilms
2022-09-20 19:57
Curious where you land on this, but one approach I have been running with recently was creating alongside the hooks that codegen apollo tool is creating for us, is an SDK with the same methods, etc. and utilizing the sdk within the test suite as opposed to hooks.
tpaktopsp
2022-09-20 20:31
I ended up writing react testing library tests and leaving `useQuery` in place. We have 80+ places where we are already using useQuery - replacing them might be quite a lot of work. Curios which codegen SDK are you referring to?
dekkofilms
2022-09-20 21:00
For sure, so for the SDK part, i added to our codegen.yml a plugin for creating a contract testing file and it's utilizing this plugin called: `"typescript-graphql-request"`
found https://www.npmjs.com/package/@graphql-codegen/typescript-graphql-request.
dekkofilms
2022-09-20 21:17
Something my mind is still a little fuzzy on is the benefit (specifically in GraphQL world) of verifying the new GraphQLInteraction added with a call to a mocked server and expecting the response to match what we would expect it to be. I think the hurdle my mind is currently trying to jump over is when would that expectation reasonably fail ... it seems like it would be a failure because I wrote the expectation wrong itself but failure wouldn't happen otherwise(?).
I think to highlight the general usecase a bit more, here is the last bit of a GraphQLInteraction and what I expect it to respond with:
```new GraphQLInteraction()
.......
.willRespondWith({
status: 200,
headers: {
'Content-Type': 'application/json',
},
body: {
data: {
addTime: {
updatedRecord: {
id: like('62edadccafea8bf4d0d17bbd'),
currentTime: like(40),
},
},
},
},
});```
Calling then a mocked Pact server, I am essentially testing that the response would also equal that response defined in the GraphQLInteraction ... so when would my expectation within the test file itself actually fail other than me intentionally (or unintentionally) not writing correctly the object to match against the response. Seems like even the unintentional failure would be more prohibitive than beneficial.
Totally could be misunderstanding the whole point (it's actually highly likely) ... but just wanted further documentation to unfuzzy this concept, and/or community discussion to help bridge this understanding in my head. Seems like, as I'm typing this, this would be more broad than just GraphQL itself and maybe it's a concept higher above I'm just not yet grasping, so would 1,000% love some insight and guidance to this scenario.
matt.fellows
2022-09-21 12:17
The point is not to test the response, it?s to unit test your GraphQL client code
matt.fellows
2022-09-21 12:18
This is a general Pact concept. Consumer tests don?t exist for drafting test cases for the provider, they are about capturing the needs of the consumer _so that_ we can ensure the provider continually supports it
matt.fellows
2022-09-21 12:19
I?m guessing maybe because GraphQL often has clients, that this makes the test somehow a bit awkward to write?
dekkofilms
2022-09-21 12:25
Yeah to your last question, I think that is kind of the case in this instance ... we don't have for example an `API` class that is a layer of abstraction over calling our provider, etc. etc. We specifically use the Apollo client which also has it's own generation tool for React applications that abstract that whole layer for us, and is simply the hooks we use within client side application code.
I totally like to continue writing tests in any organization // repository and keep the pattern fairly agnostic to the tools & framework being used, so maybe if we ever did extend out of some of the Apollo client tools directly and create our own API layered class I would see the benefit of these unit tests expectations more.
dekkofilms
2022-09-21 12:27
It just also felt weird to me from the client unit tests, to `addInteraction` but then not do any sort of test or expectation past that.
dekkofilms
2022-09-21 12:40
I think outside of GraphQL sometimes tests even when creating an interface to interact with an API kind of make the convo interesting. For instance, even in certain rest examples in the Pact world we could have a client service method like:
```const availableAnimals = () => {
return request
.get(`${getApiEndpoint()}/animals/available`)
.set(authHeader)
.then((res) => res.body);
};```
Totally understand in other instances, certain levels of client side validation or augementation could be happening outside of the network request, but in this specific instance, it seems the expectation that followed the test interaction would be minimized(?) in benefits compared to other client side unit tests with more business logic within the service method.
matt.fellows
2022-09-21 13:37
> It just also felt weird to me from the client unit tests, to `addInteraction` but then not do any sort of test or expectation past that.
wait, you definitely need to do a test. What am I missing here?
matt.fellows
2022-09-21 13:38
> Totally understand in other instances, certain levels of client side validation or augementation could be happening outside of the network request, but in this specific instance, it seems the expectation that followed the test interaction would be minimized(?) in benefits compared to other client side unit tests with more business logic within the service method.
yes, that can definitely be the case. In TypeScript, you?d often want to ensure you?re getting the appropriately typed object with all of the fields properly populated etc.
But, importantly, *only* the fields this consumer needs (and not the entire set that exist on the provider ?just because? they are there)
dekkofilms
2022-09-21 14:47
> wait, you definitely need to do a test. What am I missing here?
yea, sorry ... I guess when all the abstraction was taken away with Apollo Client and really just simply testing that calling the client gave us the response back in the expected shape, the expectation like this thread started, seemed like you could totally remove it as being unnecessary.
> But, importantly, *only* the fields this consumer needs (and not the entire set that exist on the provider ?just because? they are there)
I think this is really where it does become more GraphQL specific. In the original document above, with the `willRespondWith` query, that's being generated from a defined `.graphql` file in our client side code.
```mutation AddTime($input: AddTimeInput!) {
addTime(input: $input) {
updatedRecord {
id
currentTime
}
}
}```
There are actually a lot more fields you can pull from `updatedRecord` but in this request I'm only asking for id and currentTime. The generator will create this in such that it only returns me those two properties even though more exist as well (it's also typed in such with using Partial<> in TS).
So to some, it felt like our expectation was kind of also testing what the generator was already giving us for free. If this makes sense?
jwang
2023-02-01 22:58
Is there documentation available on how to generate a graphql provider contract for bi-directional testing?
matt.fellows
2023-02-02 01:26
We don?t support GraphQL for BDCT, unless you can document a GraphQL API as an OAS (which I don?t think you can do?)
jwang
2023-02-03 17:01
We were looking at a conversion tool such as this, https://www.npmjs.com/package/graphql-to-openapi, but it would mean another layer for potential failure.
matt.fellows
2023-02-05 23:57
Yeah I?m not convinced about that as an option, albeit looks interesting.
mikey214
2023-03-20 04:13
hey sorry to bump this, but our team was also looking into BCDT for our GQL APis and came across this exact package
I was going to experiment with this package to see if it would work out, but I wanted to hear more of your thoughts before I invest a lot of time on something that is just bound to fail
@matt.fellows? Could you maybe go a bit more in depth as to why you seem unconvinced?
matt.fellows
2023-03-21 01:07
the main reason is, it can?t express the details of the GraphQL query. Without that it?s useless because you can?t be sure the OAS actually represents your GraphQL interface
mikey214
2023-05-12 17:24
hey, not sure if this has been answered already, but is there update for PactV3 support for graphql?
matt.fellows
2023-05-15 00:57
(I just created it based off of https://pact.canny.io/feature-requests/p/v3-support-for-graphql-interactions)
lewiscowles
2023-06-22 00:12
would it make sense to pin the following gist snippet then? https://gist.githubusercontent.com/wabrit/2d1e1f9520aa133908f0a3716338e5ff/raw/9f241c56d16c295906fdb29b09d6cb2919e21ef6/GraphQLPactV3.ts and maybe associated gist
https://gist.github.com/wabrit/2d1e1f9520aa133908f0a3716338e5ff
Just in-case people get lost
vijaya.balla.external
2023-07-21 15:11
hi all :wave:,
I am looking for some help on using PACT for Apollo federated GraphQL. has anyone done this? Apologies, I can't see the slack history to search before asking. would really appreciate any help on this.
yousafn
2023-07-21 15:34
There is some discussion in these feature reqs on our canny board
https://pact.canny.io/feature-requests/p/v3-support-for-graphql-interactions
And a feature request for a graphql plugin
https://pact.canny.io/feature-requests/p/plugin-graphql
Just as a tip, you can search via http://linen.dev which presents https://docs.pact.io/slack/ in a nicer searchable way
https://www.linen.dev/s/pact-foundation/t/548324/i-ve-been-using-pact-pact-js-for-graphql-contracts-between-c#777b318a-c21d-4d63-875b-243dc0095ded
note to self: maybe add that in to the slack bot, for slack history keyboard
joel.whalen588
2023-10-06 17:13
Hey @matt.fellows long time no see, I?m coming back on my pact journey, this time using mock service worker (MSW). I?m using the msw pact package for javascript, and am running into an issue with setting up graphql handlers. The output of `server.printHandlers()` looks like this:
``` console.log
[graphql] query userAndInviteInfo (origin: *)
Declaration: /Users/joel.whalen/Documents/src/frontend-core/.yarn/__virtual__/@updater-consumer-graph-virtual-1670450a42/1/packages/consumer-graph/dist/cjs/mocks.js:1113:64```
but I?m getting a pact msw error that says it cannot find any graphql handlers:
``` ? useIsMoveUPO ? returns true if the invite is marked as residentOnboaringEnabled
Found errors on msw requests.
Requests with missing msw handlers:
http://localhost:3000/graphql
56 | });
57 | afterEach(() => {
> 58 | pactMswAdapter.verifyTest();
| ^
59 | server.resetHandlers();
60 | });
61 | afterAll(async () => {```
I?m setting up my MSW handlers like this:
```const handlers = [
mockUserAndInviteInfoQuery((req, res, ctx) => {
console.log(`Request: ${req}`);
console.log(ctx.data);
return res(
ctx.data({
getUser: {
user,
},
inviteByToken: {
invite,
},
})
);
}),
];
const server = setupServer(...handlers);```
so I?m wondering if I?m doing something wrong, since pact msw can?t see it. Thoughts?
joel.whalen588
2023-10-06 17:35
Also a more general question about graphql and how it works with pact-msw-adapter: How does the `providers` attribute work, since all providers are ?hidden? by the `/graphql` endpoint?
yousafn
2023-10-06 20:06
fyi i wrote pact msw adapter and never considered gql at all when writing it, so i wouldn?t be surprised if it doesn?t work. happy to consider pull requests :)
joel.whalen588
2023-10-06 20:34
Alright I wouldn't mind since we use MSW extensively in our gql only backend - could you point me a good place to start contributing to this package to support gql?
yousafn
2023-10-06 20:55
so it doesn?t use pact per sai, merely converts satisfied msw matches into a pact file format.
so once you have a satisfied match you can work out what data you have and munge that into a pact file format. probably having a look at the existing gql adaptor in pact js might be a start.
ps i don?t actually think graphql validation in its current guise offers huge amounts of value and a custom graphql plug-in may be more suitable - we have an open req on our feature board
joel.whalen588
2023-10-06 20:56
You mean a custom graphql plug in for pactjs? I thought it already supported gql
yousafn
2023-10-06 21:00
well it does but it?s not idiomatic for gql users
no i mean a custom pact plug-in due to some of the reasons outlined in the below feature req
https://pact.canny.io/feature-requests/p/plugin-graphql
https://docs.pact.io/plugins/quick_start
so whilst you can do gql testing, it?s probably not what users want and there are ways the experience could be improved
joel.whalen588
2023-10-06 21:01
Gotcha, I see. I'm more interested in this feature because our infrastructure is already graphql centered, so I'm just trying to work with that
yousafn
2023-10-06 21:02
btw high level this all really what pact msw adapter is doing
https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/pact#converting-mocks-into-a-pact-compatible-format
taking a known mock format and converting it into a pact json file
yousafn
2023-10-06 21:06
and this was the original feature req for msw pact
https://github.com/mswjs/msw/issues/572
happy to jam on something async if you want to give anything a start.
joel.whalen588
2023-10-06 21:08
Yeah I figured, since msw is a known format you're essentially compiling it into pactfiles. I'd love to take a look at this, though I haven't written anything at the protocol level or lower since college lol
matt.fellows
2023-10-06 23:08
> You mean a custom graphql plug in for pactjs? I thought it already supported gql
This is true, because GraphQL runs over HTTP.
The response side is purely JSON/HTTP, so it ?just works?. It?s just the consumer side. GraphQL supports two approaches:
1. query string based
2. post body
For query strings, again, this will be purely HTTP.
For post body, you could look at how we address it in Pact JS here: https://github.com/pact-foundation/pact-js/blob/master/src/dsl/graphql.ts (it?s a little adapter to make it easier to work with the usual JS DSL)
matt.fellows
2023-10-06 23:09
TL;DR - you just need to map the mocks in MSW to the pact file format (as https://pact-foundation.slack.com/archives/C0135EDRC4R/p1696626162574379?thread_ts=1696612417.796559&cid=C0135EDRC4R by Saf)
joel.whalen588
2023-10-06 23:10
Ah ok, so the mocks have been already mapped from MSW to pact for REST; I'd just have to make the same translation for graphql?
matt.fellows
2023-10-06 23:11
You could probably just look at this example here: https://github.com/pact-foundation/pact-js/tree/master/examples/graphql
And then review the generated pact file for what the end result would need to be.
I?d suggest a toggle/configuration somewhere that knows which style (post vs qs) of GraphQL it can mock (I suspect MSW knows this somewhere already(.
yousafn
2023-10-09 18:09
Hey,
So I forgot when responding, earlier that msw provider graphql mocks and I had a placeholder. ( I had moved to a new client and we weren?t using gql anyway - I only had the briefest of forays, so it wasn?t really on my radar)
> https://mswjs.io/docs/getting-started/mocks/graphql-api
> Not currently tested, please feel free to help contribute or let us know if you want to see it!
https://docs.pactflow.io/docs/bi-directional-contract-testing/tools/msw/#define-mocks
The MSW getting started guide is great start especially when thinking about the interface for users and the steps they would take to integrate msw and msw-pact-adapter.
Here is a bit of walkthrough of the interface
https://github.com/pactflow/pact-msw-adapter/blob/main/src/pactMswAdapter.ts#L44C1-L51C27
it takes a `SetupServerApi` or `SetupWorkerAPI` depending on whether its a node env or not
It then checks msws lifecycle events to listen for matches
https://github.com/pactflow/pact-msw-adapter/blob/bc5625373ddc2da27789833aad6bdbfbc6c761fb/src/pactMswAdapter.ts#L119
For any matches, we take the metadata from msw, and converts to a pact format
https://github.com/pactflow/pact-msw-adapter/blob/bc5625373ddc2da27789833aad6bdbfbc6c761fb/src/pactMswAdapter.ts#L252
this is the serialiser to convert to a pact file
https://github.com/pactflow/pact-msw-adapter/blob/main/src/convertMswMatchToPact.ts#L4
> You could probably just look at this example here: https://github.com/pact-foundation/pact-js/tree/master/examples/graphql
> And then review the generated pact file for what the end result would need to be.
This is a good idea to review the generated pact file, that is how I worked when creating the original so I had the correct structure.
It would be nice to validate it against a schema https://github.com/pactflow/pact-schemas so we knew the specs we were generating were valid, but that is a nice future goal.
If its easier just to spin up a new project rather than pre constrained by pre-existing ideas in the project, feel free! we can always integrate them later if it warrants it :slightly_smiling_face:
joel.whalen588
2023-10-10 19:05
Ok so if I'm reading all of the above code correctly, I would essentially need to write a file like `convertMswMatchToPact` but call it something like `convertMswGqlMatchToPact`, and put the serialization logic there, while using the existing pact graphql example pactfile result as a baseline. Then check my final result against the `pact-schemas` repo such that my final pact file looks right. Is this correct?
joel.whalen588
2023-10-11 19:39
is there a channel for pact msw development questions? I'm going through the `DEVELOPMENT.md` steps and am getting this
```? pact-msw-adapter git:(main) yarn run example:link
yarn run v1.22.19
$ cd examples/react && yarn link @pactflow/pact-msw-adapter
warning package.json: No license field
error No registered package found called "@pactflow/pact-msw-adapter".```
joel.whalen588
2023-10-11 21:14
how do we feel about writing a custom typescript transformer for MswGql -> Pactfile? https://levelup.gitconnected.com/writing-a-custom-typescript-ast-transformer-731e2b0b66e6
matt.fellows
2023-10-12 02:25
it sounds complicated - but sounds fun. What?s the main benefit of this over the existing approach?
joel.whalen588
2023-10-12 14:14
I'll be honest with you, it's because I learned how to use AST transformers in school with the visitor pattern for solving this exact same problem in the past, so it makes the most sense to me when talking about translating a tree of tokens (gql) into something else (pactfile)
joel.whalen588
2023-10-12 14:15
Also typescript has a transformer API that can do most of the heavy lifting, and this method seems to be the most consistent. You just list all your rules in the recursive visitor function and it should work for *any* configuration of gql msw mocks
joel.whalen588
2023-10-12 14:17
I'm probably going to try to mirror the existing function for transforming just to get it done first though
matt.fellows
2023-10-12 23:45
Makes sense. The only thing I?ll say, is that gql is wrapped in a string when it goes over the wire (i.e. it?s gql wrapped in JSON). I?m not sure how useful it will be to parse that AST Pact is _not_ aware of the AST. It will just match the gql payload matches verbatim (in Pact JS I do an ugly regex to allow white space so the tests are less brittle)
joel.whalen588
2023-10-13 00:11
I guess I could parse the string into an AST but I think I'm creating more problems than I solve at that point lol
matt.fellows
2023-10-13 00:13
See how you go. Pact could definitely improve it?s GraphQL support. I?d love to see a Plugin for GraphQL, and that would definitely need to parse the AST in some way/shape/form
yousafn
2023-10-13 17:13
as an aside on the ast stuff - the team over at Swagger have been working on this
https://github.com/swagger-api/apidom
and me and my manager have been chatting about if there would be use in having support for the pact spec.
I?m not overly familiar with it all, but interested to learn. It?s not really needed for your goals though :+1: and it a rabbit hole, probably not worth diving into at this juncture
joel.whalen588
2023-10-13 17:14
That's really cool, I hope it succeeds. But you're right that's too much for this use case
