How to use normalizeProxy method in Jest

Why does mutating a module update the reference if calling that module from another module, but not if calling from itself?

"In ES6, imports are live read-only views on exported values".

When you import an ES6 module you essentially get a live view of what is exported by that module.

The live view can be mutated, and any code that imports a live view of the module exports will see the mutation.

That is why your test works when alpha and beta are in two different modules. The test modifies the live view of the beta module, and since the alpha module uses the live view of the beta module, it automatically uses the mocked function instead of the original.

On the other hand, in the code above alpha and beta are in the same module and alpha calls beta directly. alpha does not use the live view of the module so when the test modifies the live view of the module it has no effect.

As an additional question - in this example I am mutating the module by directly reassigning properties. Am I right in understanding that using jest mock functionality is going to be essentially doing the same thing?

There are a few ways to mock things using Jest.

One of the ways is using jest.spyOn which accepts an object and a method name and replaces the method on the object with a spy that calls the original method.

A common way to use jest.spyOn is to pass it the live view of an ES6 module as the object which mutates the live view of the module.

So yes, mocking by passing the live view of an ES6 module to something like jest.spyOn (or spyOn from Jasmine, or sinon.spy from Sinon, etc.) mutates the live view of the module in essentially the same way as directly mutating the live view of the module like you are doing in the code above.

As far as I know - there is not way to mock a single function in a module, while testing that module, as this jest github issues talks about. What I'm wanting to know - is why this is.

Actually, it is possible.

"ES6 modules support cyclic dependencies automatically" which means that the live view of a module can be imported into the module itself.

As long as alpha calls beta using the live view of the module that beta is defined in, then beta can be mocked during the test. This works even if they are defined in the same module:

import * as indexModule from './index'  // import the live view of the module

export function alpha(n) {
    return `${n}${indexModule.beta(n)}${n}`;  // call beta using the live view of the module
}

export function beta(n) {
    return new Array(n).fill(0).map(() => ".").join("");
}

A working solution nowadays would be to use userEvent.tab() instead of fireEvent.keyDown().

import '@testing-library/jest-dom'
import userEvent from '@testing-library/user-event'

import { render, screen } from '@testing-library/react'
import Component from './buttons'

it('changes focus on tab', async () => {
  render(<Component />)
  const one = screen.getByTestId('one')
  const two = screen.getByTestId('two')

  one.focus()
  expect(one).toHaveFocus()

  await userEvent.tab()
  expect(two).toHaveFocus()
})

I found a way to fix it.

Steps to fix:

Open your package.json file and edit your browserslist as follows.

 "browserslist": {
   "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
},

to

"browserslist": [
   ">0.2%",
  "not dead",
  "not op_mini all"
],

Once you've done this, delete the node_modules/.cache directory.

Then try npm install.

And npm start

Tadaaa!

References:

• ?? Operator results in "Unexpected Token" err when used in package #9468
• Module parse failed: Unexpected token (10:41) in @react-leaflet/core/esm/path.js #877

This feature was added in Jest's 22 version, with globalSetup and globalTeardown configurations. Look at this for examples.

_{package.json (or in jest.config.js)}

{
  ...
  "jest": {
    "globalSetup": "./scripts/jestGlobalSetup.js"
  }
}

_{/scripts/jestGlobalSetup.js}

module.exports = async () => {
  console.log('\nhello, this is just before tests start running');
};

OR

export default async () => {
  console.log('\nhello, this is just before tests start running');
};

It seems you have DEV instead of __DEV__ in your package.json:

// ...
  "jest": {
  // ...
    "globals": {
      "__DEV__": true
    },
  // ...
  }
// ...

Jest is installed, but is likely in your ./node_modules/.bin directory. You can append that to your command ./node_modules/.bin/jest --updateSnapshot. Since you already have jest as a scripts command in your package.json you can also run it with npm test -- --updateSnapshot. npm automatically adds ./node_modules/.bin to your path.

update: Newer versions of yarn will resolve node module bin scripts, so you can also just run yarn jest {cmd} and it should work.

I think that if you don't want to use relative paths, you have to define additional moduleDirectories, like

// package.json
{
  "jest": {
    "moduleFileExtensions": ["js", "jsx"],
    "moduleDirectories": ["node_modules", "bower_components", "src"],
  }
} 

More about moduleDirectories in jest docs and configuring jest to find files.

restart metro bundler with yarn start or npm start solved my problem

I think it's worth reconsidering your assumptions...

My code widely depends on global window object (and it's methods) which isn't fully implemented by jsdom, but available in real browser environment.

Which methods from the window scope are you using that aren't in jsdom? Can you just provide a simple mock window object that contains mocked versions of these methods?

So i want to run unit tests inside puppeteer page context environment so covered code (and it's dependencies) can access real window object. ... (which kills whole unit test idea)

Once you start running your code in a browser, you may be crossing the line between unit tests and integration or end-to-end tests. I'd take a look at your code and see if you can abstract-out the logic that depends on the window scope, and concentrate on testing the non-window-dependent code.