New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds MSW + testing utilities example #11763
base: main
Are you sure you want to change the base?
Conversation
|
size-limit report 📦
|
✅ Deploy Preview for apollo-client-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
…ql/apollo-client into issue-11709-example-with-msw
"test": "jest" | ||
}, | ||
"dependencies": { | ||
"@apollo/client": "^3.10.0-rc.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will wait to merge this until the next RC is published and I can update the version here along with the new fn names
"moduleResolution": "bundler", | ||
"allowSyntheticDefaultImports": true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"moduleResolution": "bundler", | |
"allowSyntheticDefaultImports": true | |
"moduleResolution": "bundler", | |
"noEmit": true, | |
"allowSyntheticDefaultImports": true |
Otherwise, running tsc
might result in stray files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I update all the tsconfig.node.json
in integration tests?
Edit: updated 2a69c5a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like that caused tsc to error with Referenced project '/home/circleci/project/integration-tests/vite-jest-msw/tsconfig.node.json' may not disable emit.
"noFallthroughCasesInSwitch": true | ||
}, | ||
"files": ["@types/graphql.d.ts"], | ||
"include": ["src", "./tests/setupTests.js"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, no tsconfig
seems to be including the tests
folder, so everything in there will fall back to some kinda-random defaults. Is that intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Including tests
there was causing some weird failure mode either in my editor or CI (but not both)... I forget what that was :/
beforeEach(() => { | ||
// since all our tests now use our "real" production Apollo Client instance, | ||
// we need to reset the client cache before each test | ||
return client.cache.reset(); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to admit, I'm still not 100% sold on "having only one client".
I am 100% sold on "using the real client", but I wouldn't have only one of them.
(Sorry for bringing this up so late, but I'm only really realizing through reviewing these PRs, we mostly discussed other parts of the testing setup.)
My suggestion would be to establish a pattern of a makeClient()
function (maybe also a makeClient({fetch?})
function?) so that every test could use a "real" production client, but no two tests use the same - even if you reset the cache
here, the QueryManager is not reset - and it could still have pending queries, and those would be deduplicate into the next test.
For comparison, see https://redux.js.org/usage/writing-tests#setting-up-a-test-environment which suggests a setupStore
function that automatically creates a new store
in renderWithProviders
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a great call out. I'll come back and make this change once the next RC is out since I'll have to update this PR then anyways, and will incorporate that guidance into the docs I'm writing 👍
Edit: I'll actually come back around to this in a separate PR
Closes #11709. Configures initial integration tests with MSW.