Replace @fetch-mock/jest with plain fetch-mock

[mstange]

This makes the tests check what they were thinking they were checking, and gives better error messages when they fail.

---

Most of our toHaveFetched checks weren't actually checking anything.

Only the checks in shorten-url.test.ts worked. These were of the following shape:

expect(window.fetch).toHaveFetched({ body: { longUrl: expectedLongUrl } });

So they were passing a plain object literal (not an expect.objectContaining), and they were using an actual object in the body property, which fetch-mock compares against the JSON.parse'd body. This is the right way to use fetch-mock's "body matcher" and it worked.

The check in profile-store.test.ts also worked, but only by accident:

expect(window.fetch).toHaveFetched(endpointUrl, expect.anything());

We could have just removed the second argument there.

The uses in receive-profile.test.ts were not checking anything, and neither were the uses in AppLocalizationProvider.test.tsx.

Here's the use of toHaveFetched in in receive-profile.test.ts:

expect(window.fetch).toHaveFetched(
  'https://symbolication.services.mozilla.com/symbolicate/v5',
  expect.objectContaining({
    body: expect.stringMatching(/memoryMap.*firefox/),
  })
);

If we wanted to keep using toHaveFetched here, one option would be to use fetch-mock's "body" matcher, and do something like this:

expect(window.fetch).toHaveFetched(
  'https://symbolication.services.mozilla.com/symbolicate/v5',
  {
    body: { job: [...] },
    matchPartialBody: true,
  }
);

or in reality probably something more like this:

expect(window.fetch).toHaveFetched(
  'https://symbolication.services.mozilla.com/symbolicate/v5',
  {
    matcherFunction: (callLog) => {
      return (callLog.options.body as string).match(/memoryMap.*firefox/) !== null
    }
  }
);

But then the other problem is that, if these checks fail, the error messages are not all that useful. For example, if I misspell 'firefox' as 'forefix' in the example above, the error message I get is:

fetch should have been called with https://symbolication.services.mozilla.com/symbolicate/v5 and {}

Overall, my conclusion is that, if I can't use things like expect.objectContaining or expect.stringMatching with @fetch-mock/jest, then @fetch-mock/jest is not very useful and we're better off using plain fetch-mock.

Accessing lastCall() directly lets us use these Jest matchers and produces more useful errors.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.78%. Comparing base (d956b46) to head (0f4bf61).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5575   +/-   ##
=======================================
  Coverage   85.78%   85.78%           
=======================================
  Files         309      309           
  Lines       30403    30403           
  Branches     8370     8370           
=======================================
  Hits        26080    26080           
  Misses       3902     3902           
  Partials      421      421           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[canova]

Looks good to me, thanks for providing the context in the PR message!