A clear and concise description of what the bug is.
msw: 0.19.5nodejs: 12.8.2npm: 6.14.5Please also provide your browser version.
Steps to reproduce the behavior:
rest.get('/api/users*', (req, res, ctx) => {
return res(ctx.json(apiresponse))
})
when i write this on our source i get this error always.
A clear and concise description of what you expected to happen.
If applicable, add screenshots to help explain your problem.
Hey, @manishiitg. Thanks for reporting this.
Please, could you include a code snippet on how you perform a request? For example, it can be a fetch() or http.request() call. The issue it about HTTP protocol misalignment, and it's crucial to know what exact resource you are requesting.
Also, are you running your mocks in browser or NodeJS (I assume NodeJS, but need to double check)? If so, is there are other setup you do around setupServer? Thanks.
Hi @kettanaito
This is how i call the actual api
fetch("https://reqres.in/api/users?page=1")
I am running mocks on nodejs.
no other setup for "setupServer" just the basic
Also. another thing. i am running my tests on windows wsl2.0 if that makes any difference.
The issue is that relative URLs do not exist in NodeJS. All requests in NodeJS must have an absolute URL (either explicit or implicit).
When you write /api/users in your request handler route, it's always transformed into an absolute URL. When it's running in a browser, it's matched against the current location.origin. In NodeJS, there is no such concept as "location". However, certain DOM-like environments (like jsdom) polyfill location and set it to a hard-coded "localhost:XXXX" string. This is the reason why a relative route may work in both in-browser development and integration tests that run in NodeJS.
You can choose one of the following ways to solve this issue:
setupServer(
rest.get('https://reqres.in/api/users', (req, res, ctx) => res(ctx.json({ mocked: true })
)
This approach is preferable, just make sure you request the same endpoint during development, or in a browser (if applicable). If using the same absolute request URL is constrained (for any reasons), consider having a different request URL depending on the environment. For example:
const ORIGIN = process.env.NODE_ENV === 'test'
? 'https://reqres.in'
: ''
setupServer(
rest.get(`${ORIGIN}/api/user`, (req, res, ctx) => res(ctx.json({ mocked: true })
)
You can abstract this URL origin logic into a custom function to prevent repetition.
setupServer(
rest.get('*/api/users', (req, res, ctx) => res(ctx.json({ mocked: true })
)
This is generally not recommended, because this will match all requests that end with /api/users. For example, if your app performs a https://google.com/api/users request, that one would get matched as well.
I can also suggest to omit the * (asterisk) at the end of your route. Request query parameters and hash are stripped off, and never taken into account when matching requests. However, by making a permissive route like /api/users* you also match against any child route (i.e. /api/users/messages/abc-123).
i guess this this official example should be updated
https://testing-library.com/docs/react-testing-library/example-intro
That example is correct. As I've mentioned before, jsdom (environment created by Jest) polyfills location, so the /greeting URL becomes http://localhost:XXXX/greeting, which would equal the location where the app is running during the test (despite the test running in NodeJS). The test suite showcased in the React Testing Library example runs in Jest.
When performing a request in NodeJS directly (without any implicit environments), one needs to always have an absolute URL.
ok. thanks. issue solved and understood
Do you mind sharing your end solution? I'm curious.
I've added a Node integration > Direct usage section that explains why this issue occurs and how you should use setupServer in NodeJS.
Hi @kettanaito ,
Thanks for detailed explanation and I've configured the server exactly as you told, but the issue still persists. I've got the same basic setup. I've even found the similar code example. What else do you think we could try to solve it?
@mikhailbalin, hey. We've released a fix that may solve the issue you're experiencing (https://github.com/mswjs/node-request-interceptor/pull/62). Could you re-install your dependencies (msw package)?