Test with rejected Promise fails in Node, not in browser

[ghengeveld]

Relevant code

import React from "react"
import { render } from "@testing-library/react"

const Hello = () => {
  const promise = Promise.reject("Oh no!")
  console.log(promise)
  return <div>Hello RTL</div>
}

test("HelloRTL", async () => {
  const { findByText } = render(<Hello />)
  await findByText("Hello RTL")
})

The problem

Ran from the command line with yarn test --watchAll, this fails with the following output:

 FAIL  src/hello.spec.js
  ✕ HelloRTL (22ms)

  ● HelloRTL

    Oh no!



  console.log src/hello.spec.js:6
    Promise { <rejected> 'Oh no!' }

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        0.774s, estimated 1s
Ran all test suites.

Reproduction

• Naturally I've setup a CodeSandbox.
• As you can see the test actually passes in CodeSandbox, I suppose this is because it's run in the browser?
• I've setup a repository here.
• I've added the repo to Travis, where you can see it fail.
• I've tried using plain Jest, where this issue doesn't appear.
• I've tried without react-scripts, but the issue persists.
• I've tried jest-environment-jsdom-fourteen, but the issue persists.
• I was able to pin this down to v8.0.6. In v8.0.5 it works fine.

Expected outcome

I would expect the test to pass in both environments. There is nothing wrong with assigning a rejected Promise to a variable, as long as it doesn't get rendered. The React component works fine.

[kentcdodds]

My guess is this is a codesandbox bug. Is there a real world scenario that you can point us to for how this is issue impacting you?

[kentcdodds]

Also, this seems unrelated to react testing library. Could you verify that it's an issue in RTL?

[ghengeveld]

It was introduced in v8.0.6. My use case is React Async, which keeps a promise in local state (via useReducer). If this is a rejected promise (which naturally is something I want to test against), the test blows up.

[kentcdodds]

That's pretty strange. Would you mind doing a little digging to see if you can figure out why this is happening?

[ghengeveld]

You should know this whole thing was actually triggered by the promise prop I recently introduced. It's becoming a bit problematic. Any help would be appreciated.

Anyway, I'll see what I can do to further pin down the issue.

[ghengeveld]

Interestingly, I was able to bring down act-compat.js to just a few lines of code to make it work:

import {act} from 'react-dom/test-utils'

act(() => ({
  then: () => {},
}))

export const asyncAct = act
export default act

Turns out this little gem was removed in the 8.0.6 release.

Obviously this completely breaks the actual act compatibility, but it shows the gist of it.

[ghengeveld]

As expected, the test passes once I call act like above:

import React from "react"
import { render } from "@testing-library/react"
import { act } from "react-dom/test-utils"

act(() => ({ then: () => {} })) // this fixes the test
  .then(() => {})               // this suppresses the "act without await" warning

const Hello = () => {
  const promise = Promise.reject("Oh no!")
  console.log(promise)
  return <div>Hello RTL</div>
}

test("HelloRTL", async () => {
  const { findByText } = render(<Hello />)
  await findByText("Hello RTL")
})

PASS src/hello.spec.js
  ✓ HelloRTL (21ms)

  console.log src/hello.spec.js:11
    Promise { <rejected> 'Oh no!' }

[kentcdodds]

The problem is that we need to support 16.8 for the foreseeable future. That's why act-compat exists 😬

[ghengeveld]

Yes, but I'm sure we can just put that little snippet back in at the right place to fix this issue, while keeping the whole compat thing. I only brought it down to the bare minimum for debugging purposes.

[ghengeveld]

By the way relative-deps has been indispensable to get my local fork of react-testing-library into the example repo. Symlinking doesn't work due to both depending on different instances of react and react-dom.

[ghengeveld]

I've pushed the workaround to the demo repo and confirmed that this fixes the test.

[gnbaron]

I'm experiencing a similar issue I guess, but I'm pretty sure it has something to do with 16.9.0. You can confirm that downgrading react and react-dom to 16.8.0 in your demo repo, tests will pass even without your workaround.