-
Notifications
You must be signed in to change notification settings - Fork 2
Description
Hey! So excited to finally see this library out!
I will provide a few code review and suggestions below. Feel free to convert this to a discussion or whichever format is more suitable for you.
graphql-testing-library/src/handlers.ts
Lines 92 to 94 in e18caf4
| // @ts-expect-error FIXME: mismatch on the return type between HttpResponse | |
| // with a stream vs. json | |
| >(async ({ query, variables, operationName }) => { |
This isn't something MSW can solve with the current version range of TS we support, unfortunately. You can learn more about why here: mswjs/msw#1691.
Solution: Provide a union of expected response types to the handler. I'm not sure if graphql.*() functions support that right now though. It looks like they infer the response resolver (and its return type) from the query. Let me know if this turns problematic, we can work on a solution for it.
graphql-testing-library/src/handlers.ts
Lines 163 to 164 in e18caf4
| const randomDelay = Math.random() * (delayMax - delayMin) + delayMin; | |
| await wait(randomDelay); |
It would be great to let the folks use the built-in delay values too, like infinite or random server response time. Looks like a change here.
For debugging reasons, it would be nice to see what schema was used when a handler was run. You can achieve that by creating a custom request handler instead of wrapping graphql.operation(). You can then define its log() method to include the schema when debugging handlers.
I think that can be handy given you can swap the schema mid-test. You also get access to internal caching API which you can use to cache any computation you need (like gql(query) or AST parsing, if that makes sense).
If you have any questions about the WebSocket mocking, please let me know.