requestHandler override isn't immediately used in test
See original GitHub issueEnvironment
Name | Version |
---|---|
msw | 0.27.1 |
node | v12.20.1 |
OS | MacOS |
Request handlers
// Example of declaration. Provide your code here.
import { setupServer } from 'msw/node'
import { rest } from 'msw'
const server = setupServer(
graphql.query("Roles", (_req, res, ctx) => res(ctx.data({}))) // return empty object by default
)
server.listen()
Test code
Actual request
// apollo useQuery hook
export const ROLES_QUERY = gql`
query Roles {
roles
}
`
const { data, error } = useQuery(ROLES_QUERY)
console.log('data', data)
test code that fails (using @testing-library/react)
test("some roles query test", () => {
server.use(
graphql.query("Roles", (req, res, ctx) =>
res(
ctx.data({
roles: ["roleA", "roleB"],
}),
),
),
)
render(<HeaderMenu />)
// logs data: {}
test code that succeeds
test("some roles query test", async () => {
server.use(
graphql.query("Roles", (req, res, ctx) =>
res(
ctx.data({
roles: ["roleA", "roleB"],
}),
),
),
)
// only difference here
const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms))
await wait(0)
// only difference here
render(<HeaderMenu />)
// logs data: { roles: ["roleA", "roleB"]}
Current behavior
apollo query returns data: {}
Expected behavior
apollo query to return data: { roles: ["roleA", "roleB"] }
Thoughts + Question
This was a head-scratcher to figure out. Especially as server.printHandlers()
run directly after server.use() did always indicate the override as succeeding.
Is there a more elegant way to solve this do you think? Or have a better idea of the root cause of why this wait(0) is needed? Has anyone else has run into issues like this?
Issue Analytics
- State:
- Created 2 years ago
- Reactions:8
- Comments:15 (7 by maintainers)
Top Results From Across the Web
SolrJ not setting request handler - Stack Overflow
It's true that the visible effect in the "setRequestHandler" method is to just set the qt parameter. But that's not the end of...
Read more >A Comprehensive Guide to Mock Service Worker (MSW)
Request handler overrides If you read the MSW documentation carefully, you may be tempted to use the one-time override (res. once()) for...
Read more >Testing AWS Lambda functions written in Java
public class Handler implements RequestHandler<Map<String,String>, String> { @Override public String handleRequest(Map<String,String> event, ...
Read more >Testing Your (HTTP) Handlers in Go - questionable services
A typo in your tests can cause unintended behaviour, becasue you're not testing what you think you are. You should also make sure...
Read more >A testing guide for Express with request and response ...
The approach detailed in this post will be about how to test handlers independently of the Express app instance by calling them directly...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I could not reproduce the issue with fetch, and I did find an issue on swr that was closed with a resolution on July 22nd. I tested with the resolution in their docs ( https://swr.vercel.app/docs/advanced/cache#reset-cache-between-test-cases ), and did not have any issues after implementing that.
For those that don’t want to click links, add an empty provider to your SWRConfig for tests:
I was able to reproduce the issue here using swr and msw https://github.com/agiveygives/msw-runtime-handler-issue
It will pass about 50% of the time.
Here are the two api responses and handler lists
using the initially configured handlers
using the runtime handler