Mock a request with a dynamic query parameter

[kr8n3r]

I'm looking at a way to intercept a request that the underlying platform provides which looks like

/v2/user_provided_service_instances?q=space_guid:${spaceGUID}
and mock a response with dummy data.

Current Nock implementation is

const spaceGUID = '38511660-89d9-4a6e-a889-c32c7e94f139';

nock
  .get(`/v2/user_provided_service_instances?q=space_guid:${spaceGUID}`)
  .reply(200, data.userServices)

Trying with

http.get(`/v2/user_provided_service_instances?q=space_guid:${spaceGUID}`, () => {
      return HttpResponse.json(data.userServices)
    }),

just throws

[MSW] Found a redundant usage of query parameters in the request handler URL for "GET /v2/user_provided_service_instances?q=space_guid:38511660-89d9-4a6e-a889-c32c7e94f139". Please match against a path instead and access query parameters in the response resolver function using "req.url.searchParams".

Any suggestions greatly appeciated

[kettanaito]

Hi, @kr8n3r. That's a great question.

As the warning suggests, you shouldn't put search parameters in the request handler URLs. Those will have no effect.

Instead, to match the requests you want, provide the path to the resource and access the value of the q search parameter in the response resolver. Then, decide how to handle the request based on that parameter's value.

http.get('/v2/user_provided_service_instances', ({ request }) => {
  const url = new URL(request.url)
  const q = url.searchParams.get('q')

  // Return a mocked JSON response if the "q"
  // search parameter equals to a specific value.
  if (q === 'space_guid:ABC-123') {
    return HttpResponse.json({ mocked: true })
  }
})

Learn more about working with Query parameters.

[kr8n3r]

great thanks. I assume it's similar syntax for multiple search params like ?order_by=-updated_at&page=1&per_page=25 ?

[kettanaito]

Yes, it's the same. You can use .get() to get individual values by name, the .getAll() method to retrieve the list of value for the same-named search parameters, or even .entries() to grab all the search parameters as an object. All of that is a standard JavaScript API.

[kr8n3r]

while above works for most requests, some mocking some api endpoints fails

example for

      bc.getBillableEvents({
        orgGUIDs: ['org-guid-bad-price'],
        rangeStart: new Date('2018-01-01'),
        rangeStop: new Date('2018-01-02'),
      }),
    ).rejects.toThrow(/failed to parse 'not-a-number' as a number/);

where getBillableEvents uses Axios and has

 if (response.status < 200 || response.status >= 300) {
    const msg = `BillingClient: ${reqWithDefaults.method} ${reqWithDefaults.url} failed with status ${response.status}`;

This is where MSW fails AssertionError: expected [Function] to throw error matching /failed to parse 'not-a-number' as a n…/ but got 'data.map is not a function' as it tries to parse data

http.get(`${config.billingAPI}/billable_events`, ({request}) => {
        const url = new URL(request.url)
        const q = url.searchParams.get('org_guid')
        if (q === 'org-guid-bad-price&range_start=2018-01-01&range_stop=2018-01-02') {
          return new HttpResponse(
            `[{
              "event_start": "2018-04-20T14:36:09+00:00",
              "event_stop": "2018-04-20T14:45:46+00:00",
              "price": {
                "ex_vat": "not-a-number",
                "inc_vat": "1.0",
                "details": []
              }
            }]`
          )
        }
      })

but mocking with query strings

http.get(`${config.billingAPI}/billable_events?range_start=2018-01-01&range_stop=2018-01-02&org_guid=org-guid-bad-price`, () => {
        return new HttpResponse(
          `[{
            "event_start": "2018-04-20T14:36:09+00:00",
            "event_stop": "2018-04-20T14:45:46+00:00",
            "price": {
              "ex_vat": "not-a-number",
              "inc_vat": "1.0",
              "details": []
            }
          }]`
        )
      })

the test passes, but MSW shows the warning for Q strings

[kettanaito]

That is a false positive test pass. MSW removes all search parameters and you mustn't include them in the request handler's URL. What happens now, you're just matching ``${config.billingAPI}/billable_events`, disregarding the search params. This means requests with different search params will also match that handler, which is not what you want.

Look into what your test is doing and adjust it accordingly. That error is not specific to MSW.

[sanks]

Hey @kettanaito
Is there any way to suppress this warning?
We are using HATEOAS to pass API URLs from backend to frontend and it works this way, that we need to have something like this at the end of the URLs that need to be mocked: ?page=2.

Thanks in advance.

[kettanaito]

Why would you not rather remove search parameters from the request handler paths? You define those paths yourself. Search parameters do not describe the resource path, it's extra payload passed alongside the request. I'd encourage that instead.

There's no way to suppress the search parameters warning at the moment because that indicates you using MSW wrong.

[sanks]

Thanks! that works.