Jest

Since you have already mocked the axios class, one of the ways of mocking the return value of axios.get is to do this:

axios.get = jest.fn().mockResolvedValue({
  data: [
    {
      userId: 1,
      id: 1,
      title: 'test'
    }
  ]
});
.
.
expect(axios.get).toHaveBeenCalledTimes(1);

Alternatively, you can spy on axios.get(), and provide a mocked return value:

jest.spyOn(axios, 'get').mockResolvedValueOnce({
  data: [
    {
      userId: 1,
      id: 1,
      title: 'test'
    }
  ]
});

There are several things that are causing trouble. First, as mentioned in jest docs:

A limitation with the factory parameter is that, since calls to jest.mock() are hoisted to the top of the file, it's not possible to first define a variable and then use it in the factory. An exception is made for variables that start with the word 'mock'. It's up to you to guarantee that they will be initialized on time!

What that means is you need to move around the lines of code to make them look like this:

  // First the mock functions
  const mockMethod1 = jest.fn();
  const mockMethod2 = jest.fn();
  
  // Only then your imports & jest.mock calls
  import File3 from "./File3";
  import File2 from "../Folder2/File2";

  jest.mock('../Folder2/File2', () => ({
    // ...
  }));

The second issue is that you are mocking File2 as if it was exporting method1 and method2, you are not mocking method1 and method2 of the File2 class! Take a look at 4 ways of mocking an ES6 class in jest docs.

The problem is that you are replacing the function after you have already given the original function to React. The expression onSubmit={this.done} is that function, and that is set as the event handler. After the render function finishes, you replace instance.done but React already got the old function. What you should do is instead:

<form className="myForm" onSubmit={() => this.done()}>

This makes sure that the event handler always invokes the method on the instance (the one you replaced). This has the nice side effect of being future compatible with React, since they will stop autobinding all methods to the instance.

Had same issue. I was able to get same result as in CI/other machines by switching terminal where I was running the command. In my case VS Code terminal was printing incorrectly and iTerm/Mac Terminal worked correctly.

A solution that worked for me is:

1. npm i full-icu
2. Run your test with NODE_ICU_DATA=node_modules/full-icu jest

Try the code below:

import {describe, expect, it } from '@jest/globals'

if you prefer explicit imports, you can do import {describe, expect, test} from '@jest/globals'.

Source https://jestjs.io/docs/en/api

Update, by a two years wiser version of me

The property .resolves of an expectation object created by expect() is also an expectation object that has the same properties (the matchers) as a regular expectation object. The only difference is that it expects the actual value to be a Promise and the matchers apply to the resolved value, not to the promise.

If the promise returned by the function resolves it means that it does not throw (if it throws then it is rejected, not resolved).
Let's express this expectation in Jest code:

it('resolves', async () => {
    await expect(foo()).resolves.not.toThrow();
});

What is wrong with your code

You have tried:

expect(await foo()).resolves.toBe(42)

It doesn't work this way because the result of await foo() is not a Promise but the resolved value of the Promise returned by foo() (assuming it resolves).
.resolves.toBe() expects a Promise, Jest complains and the test fails.

When await is in front of the expect(), foo() returns a Promise, expect() wraps it into a object whose .resolves.toBe...() returns another Promise and await awaits for it.

The general rule is: if you put await inside the call to expect() then you cannot use .resolves or .rejects because the value that expect() receives is not a Promise. In order to use .resolves or .rejects, the await keyword should stay in front of the expect() call. Alternatively you can return the Promise instead of await-ing for it.

Read more about .resolves and .rejects.

Older answer

If you know that foo() always resolves to a value then you can use .toBeDefined():

it('resolves', async () => {
  await expect(foo()).resolves.toBeDefined();
});

This doesn't work if foo() completes using return undefined or return (without a value) or it doesn't use return at all.

In this case you cannot use .resolves but you can simply return the Promise returned by foo() and Jest takes care of the rest:

it('resolves', () => {
  return foo();
});

hmm if you are trying to test async request you should follow what is written here: https://jestjs.io/docs/en/tutorial-async

for the short version your test should look something like this:

it('works with async/await', async () => {
  expect.assertions(1);
  const data = await user.getUserName(4);
  expect(data).toEqual('Mark');
});

So, many thanks to the Jest folks on Discord. It's possible to actually clear the modules from the cache with the jest.resetModules() function.

So my test.ts file will look as follows:

describe("Localisation initialisation", () => {
    beforeEach(() => {
        jest.resetModules();
    });

    it("Sets language", () => {
        const localisation = require("./localisation");
        // Perform the tests
    });

    it("Sets english messages", () => {
        const localisation = require("./localisation");
        // Perform the tests
    });

    it("Sets french messages", () => {
        const localisation = require("./localisation");
        // Perform the tests
    });
});

The beforeEach() call to jest.resetModules() ensures we're re-running the code in the module.