jest: The `unhandledRejection` handler is not testable anymore.

GitHub bot wants to close this, but it is as relevant as ever. Adding workarounds is ok-ish in our own codebase, but when contributing to other repos this is a bit much and a proper solution would be appreciated.

Has anyone found a workaround for this issue?

Same problem here… trying to test my error handling (logging, Sentry reporting). It works fine in my other app that uses mocha for its tests, but Jest just won’t let me do it.

Is there an non-workaround/official/recommended approach for testing uncaught rejections or errors? Tagging latest contributors: @mrazauskas @SimenB ?

Half a workaround is to put this inside jest.config.js, since it’s being read before the process object is replaced by the (broken) mock:

const actualProcess = process
process.actual = () => actualProcess

(note it has to be a getter function as shown and not a property as it will not work for some weird reason related to the mock proxy)

Then in the test:

declare const process: any
beforeAll(() => process.actual().removeAllListeners('uncaughtException'))

...

  it('errors', () => {
    queueMicrotask(() => {
      throw new Error('some error')
    })

    return new Promise(resolve =>
      process.actual().once('uncaughtException', (error: Error) => {
        expect(error.message).toContain('some error')
        resolve(null)
      })
    )
  })

Same process for unhandledRejection i suppose.

If you want to be really nitpicky you’d want to reintroduce the listeners you removed, such as described here, which was the original idea for this trick - except we don’t need to create new scripts.

Any update on this issue yet?

Any update? This regression has been open for more than three years… Jest 27 in Node.js 16 is dying because UnhandledPromiseRejection is not captured, while it should be done and mark the test as failed, showing the original error, not the exception about the error not being captured.

This should be resolved because unhandledPromiseRejection might make random subsequent test fail.

Confirming the bug with a simple example:

test('catches unhandled rejections', async () => {
  const errorHandler = jest.fn();
  const error = new Error('mock error');
  process.on('unhandledRejection', err => errorHandler(err))
  await Promise.reject(error);
  expect(errorHandler).toHaveBeenCalledWith(error);
});

will give you this

● catches unhandled rejections

mock error

  13 |
  14 | test('catches unhandled rejections', async () => {
> 15 |   const error = new Error('mock error');
     |                 ^
  16 |   const errorHandler = jest.fn();
  17 |   process.on('unhandledRejection', err => errorHandler(err))
  18 |   await Promise.reject(error);

  at Object.<anonymous>.test (test/bin.test.js:15:17)

OS: macOs 10.13.6 Node: v8.11.4 (LTS) Yarn: 1.9.4

I also took this to StackOverflow: https://stackoverflow.com/questions/52493145/how-to-test-a-unhandledrejection-uncaughtexception-handler-with-jest

I ran into this problem too

Setup file: https://github.com/icecream17/solver/blob/7acc0aaae5bee787cc65670c17b21c846b360ba3/src/setupTests.ts#L1-L14

Github action:

https://github.com/icecream17/solver/runs/2720074223?check_suite_focus=true

I was able to fix this by creating a bootstrap file which runs right before Jest and stores the original process instance in a global variable! I’ve written a blog post about it: https://johann.pardanaud.com/blog/how-to-assert-unhandled-rejection-and-uncaught-exception-with-jest/

Once the bootstrap is setup, you will be able to write your tests just like this:

test('promise is rejected', async () => {
  const unhandledRejectionPromise = new Promise((resolve) => {
    process._original().on('unhandledRejection', resolve)
  })

  Promise.reject('test')

  await expect(unhandledRejectionPromise).resolves.toBe('test')
})

This prevents making the test fail when there is an unhandled promise in the code. It is a problem because developers are not aware there is something to fix since the test is marked successful. If there is only one test we could ask the dev to check the “UnhandledPromiseRejectionWarning” is not present in the logs before they merge, the problem is there are many tests and those warnings might be easily unseen as long as the tests are green. We then end up with many unhandled promises in the tests that might disrupt the execution of tests in our CI, and also many unhandled promises unfixed in the code, it is really bad.

After some tests, it is not possible to listen to the process events because it is not the real one (why?), we can’t exploit its stdout either, the stdout of the test can’t be piped 😦. Even if we could exploit stdout, what we need is to fail the test to prevent the merge, so it should be done in the jest run. I haven’t found any workaround. This was possible to fix in jest 24 by listening to the process “unhandledRejection” event but not possible in jest 26 because process is not the real one.

Please help?

This happens because jest mocks the global process object, which prevents access to the real unhandledRejection event. I couldn’t find any way to circumvent the mock or register an unhandledRejection event for a single test.

Confirmed that this breaks testing functions that throw uncaught exceptions, too: https://repl.it/repls/FreeFluffyAdministration

Not to dredge up the dead but I have a similar issue with testing unhandledrejection. Consider

window.addEventListener('unhandledrejection', event => this.onUnhandledRejection(event), {
    passive: true,
})

This code should take any unhandled promise rejection and work with it.

It works in browser but I think jsdom or jest doesn’t support it. For now I have the line ignored but it would be nice to have.

OS: Windows 10 Node: 10.7.0 NPM: 6.0.0