Putting aside any discussion about whether making actual network calls in unit tests is best practice...

There's no reason why you couldn't do it.

Here is a simple working example that pulls data from JSONPlaceholder:

import 'isomorphic-fetch';

test('real fetch call', async () => {
  const res = await fetch('https://jsonplaceholder.typicode.com/users/1');
  const result = await res.json();
  expect(result.name).toBe('Leanne Graham');  // Success!
});

With all the work Jest does behind the scenes (defines globals like describe, beforeAll, test, etc., routes code files to transpilers, handles module caching and mocking, etc.) ultimately the actual tests are just JavaScript code and Jest just runs whatever JavaScript code it finds, so there really aren't any limitations on what you can run within your unit tests.

I came across this problem while integrating codePush into the React Native app I am currently working on. What worked for me was:

1. Creating a file __mocks__/react-native-code-push.js.

Adding the following code to it:

const codePush = {
  InstallMode: {ON_NEXT_RESTART: 'ON_APP_RESTART'},
  CheckFrequency: {ON_APP_RESUME: 'ON_APP_RESUME'}
};

const cb = _ => app => app;
Object.assign(cb, codePush);
export default cb;

On my index.js file, I have:

import codePush from 'react-native-code-push';
import MyApp from './src/'

const codePushOptions = {
  installMode: codePush.InstallMode.ON_NEXT_RESTART,
  checkFrequency: codePush.CheckFrequency.ON_APP_RESUME
};

export default codePush(codePushOptions)(MyApp);

Solved removing packages-lock.json and running again using NodeJS 14 (was 10)

I use "waitForSelector" method and after that try to get the text

await page.waitForSelector('your selector')
let element = await page.$('your selector')
let value = await page.evaluate(el => el.textContent, element)

Webpack 4

As of today (April 11, 2018), most of the plugins I've tried use the deprecated API resulting in this warning:

DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead

It pleased me to find that you can easily write an ad-hoc webpack plugin (docs).

In your webpack.config.js file:

const exec = require('child_process').exec;

module.exports = {

  // ... other config here ...

  plugins: [

    // ... other plugins here ...

    {
      apply: (compiler) => {
        compiler.hooks.afterEmit.tap('AfterEmitPlugin', (compilation) => {
          exec('<path to your post-build script here>', (err, stdout, stderr) => {
            if (stdout) process.stdout.write(stdout);
            if (stderr) process.stderr.write(stderr);
          });
        });
      }
    }
  ]
};

If you'd rather use spawn to get real-time or "live" data from your script, this illustrates the basic usage:

const spawn = require('child_process').spawn;

const child = spawn('<your script here>');
child.stdout.on('data', function (data) {
    process.stdout.write(data);
});
child.stderr.on('data', function (data) {
    process.stderr.write(data);
});

The ref is attached to an instance of the component hence you will have to use mount to get an instance of the component.

To test for the ref, add the following line

expect(wrapper.instance().refInput).toBeTruthy();

Final result:

render() {
  return (<Input
    id='foo'
    ref={input => { this.refInput = input }}
  />)
}

it('should render Input', () => {
  const wrapper = mount(<Component />);
  expect(wrapper.find(Input)).toHaveLength(1)
  expect(wrapper.instance().refInput).toBeTruthy();
})

Updated with working examples. Added a styled-components example.

Here's how I solved it with Jest (uses different assertions, but concept is the same):

// setup
const MyComponent = React.forwardRef((props, ref) => (
    <div>
        <span ref={ref}>some element</span>
    </div>
))

// test
it('should contain the forwarded ref in the child span', () => {
    const ref = React.createRef()
    const component = mount(
        <Fragment>
            <MyComponent ref={ref} />
        </Fragment>,
    )

    expect(component.find('span').instance()).toEqual(ref.current)
})

• The idea is to get the instance of the element that has the ref.
• It seems to only work when wrapping MyComponent in another element, I used Fragment.

I ran into some trouble when using **Styled-Components. This is because it creates a number of extra elements. Try debugging with console.log(component.debug()). It will show you what enzyme renders.

When debugging you'll see that Styled-Components uses the recommended way to forward props.

You can find the right element using the property selector for forwardedRef:

// setup
const El = styled.div`
    color: red;
`

El.displayName = 'El'

const MyComponentWithStyledChild = React.forwardRef((props, ref) => (
    <El ref={ref}>some element</El>
))

// test
it('should contain the forwarded ref in a rendered styled-component', () => {
    const ref = React.createRef()
    const component = mount(
        <Fragment>
            <MyComponentWithStyledChild ref={ref} />
        </Fragment>,
    )

    // Styled-components sets prop `forwardedRef`
    const target = component
        .find('[forwardedRef]')
        .childAt(0)
        .instance()

    expect(target).toEqual(ref.current)
})

• You can use the same trick if you created a Higher order Component (HoC) where you need to pass ref

Yup, I think you need to update your tests. This is what the docs say, in the resetModules configuration switch section:

... each test file gets its own independent module registry.

This tallies with the behaviour I've observed. For each test file the whole runtime is rebuilt, meaning all modules are imported from scratch. That makes sense, because it means that common test bugs related to mutable global state not being cleaned up between tests are eradicated.

Also, it's worth noting jest can (if not always does) use subprocesses to run each test, so that it can be parallelized more easily, which is another reason why it makes sense to do a completely fresh setup for each test file. You can switch this off by using --runInBand, but that doesn't change the behaviour, see the example below.

On a default install, you can see the problem by simply putting a console.log() statement in an import file, and then having two tests import it, something like:

mylib.js

console.log('Hello from mylib.js!');

jests/test1.js

const mylib = require('../mylib');
describe('test1', () => {
  it('should be equal', () => {
    expect(1).toEqual(1);
  });
});

jests/test2.js

const mylib = require('../mylib');
describe('test2', () => {
  it('should be equal', () => {
    expect(2).toEqual(2);
  });
});

I get output along the lines of:

 3.2: npm run jest -- --runInBand jests/test*

> fgamelib@0.1.0 jest /path/to/cwd
> jest "jests/test1.jest.js" "jests/test2.jest.js"

(node:60746) ExperimentalWarning: The fs.promises API is experimental
 PASS  jests/test1.jest.js
  ● Console

    console.log
      Hello from mylib.js!

      at Object.<anonymous> (mylib.js:1:9)

 PASS  jests/test2.jest.js
  ● Console

    console.log
      Hello from mylib.js!

      at Object.<anonymous> (mylib.js:1:9)


Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.075 s
Ran all test suites matching /jests\/test1.jest.js|jests\/test2.jest.js/i.

Simplified version, which also works:

import * as redux from 'react-redux'

jest
  .spyOn(redux, 'useSelector')
  .mockReturnValueOnce('first call')

Also, instead of relying on multiple calls to mockReturnValueOnce it's better to just stub the necessary part of the store:

const locale = 'en'

const state = {
  application: { locale },
}

jest
  .spyOn(redux, 'useSelector')
  .mockImplementation((callback) => callback(state))