test(ramp): add useFiatCurrencies tests

[wachunei]

Description

This PR adds tests for the useFiatCurrencies hook in Ramp folder.

Related issues

Fixes: N/A

Manual testing steps

N/A

Screenshots/Recordings

N/A

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: f71809a
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/c24d6922-9a38-4189-8059-0af984eb4002

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[github-actions]

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: 48b3fbf
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/fdf67ea7-e9cc-4ad9-be0a-9fa94aec6d3e

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[georgeweiler]

awesome! I have a small suggestion for cleaning up this file, but it's a nit. I see some re-used data passed to useSdkMethod. We could extract it out as default values to make each test a bit more readable:

I haven't run this code, but something like this might be helpful:

const mockUseSDKMethod = (defaultFiatCurrency, fiatCurrencies, isFetchingDefault = false, isFetchingFiat = false, errorDefault = null, errorFiat = null) => {
  (useSDKMethod as jest.Mock)
    .mockReturnValueOnce([
      {
        data: defaultFiatCurrency, // HERE - we can pass just the data and abstract away the boilerplate
        error: errorDefault,
        isFetching: isFetchingDefault,
      },
      jest.fn(),
    ])
    .mockReturnValueOnce([
      {
        data: fiatCurrencies,
        error: errorFiat,
        isFetching: isFetchingFiat,
      },
      jest.fn(),
    ]);
};

and then the test could look like this:

it('should call useSDKMethod with correct parameters when buying', () => {
    mockUseSDKMethod([], []); 
    renderHookWithProvider(() => useFiatCurrencies());

    expect(useSDKMethod).toHaveBeenCalledWith(
      'getDefaultFiatCurrency',
      'test-region-id',
      'test-payment-method-id',
    );

    expect(useSDKMethod).toHaveBeenCalledWith(
      'getFiatCurrencies',
      'test-region-id',
      'test-payment-method-id',
    );
  });

another example:

  it('does not select the default fiat currency if current selection is available', () => {
    mockUseRampSDKValues.selectedFiatCurrencyId = 'test-fiat-currency-id-2';
    
    mockUseSDKMethod({ id: 'default-fiat-currency-id' }, [
      { id: 'test-fiat-currency-id-1' },
      { id: 'test-fiat-currency-id-2' },
      { id: 'default-fiat-currency-id' },
    ]);
    
    renderHookWithProvider(() => useFiatCurrencies());

    expect(
      mockUseRampSDKValues.setSelectedFiatCurrencyId,
    ).not.toHaveBeenCalled();
  });

[georgeweiler]

Approved with a nit to consider.

[wachunei]

I see the direction of your comment but I think another layer of indirection would be mostl helpful for default-ish cases. In this case I vary the combinations for the two sets of { data, error, loading } a lot.

In the abstracted method there are already 6 arguments and there's still missing two more for the jest.fn()s that are mocked sometimes

So in most cases it won't look like this mockUseSDKMethod([], []); but mockUseSDKMethod( /* an array of 8 args*/), which might get confusing to understand what is what because of the default arguments requirement to be present to keep their position, unless we want to add code to identify the type to correctly position the argument, which is now worse than the plain mocking it is now.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud