Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • C create-react-app
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,547
    • Issues 1,547
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 417
    • Merge requests 417
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Meta
  • create-react-app
  • Issues
  • #3038
Closed
Open
Issue created Aug 31, 2017 by Administrator@rootContributor

Test failures are obscured by the undhandledRejection throwing in test.js

Created by: cobyrne-pivot

Is this a bug report?

Probably more of an enhancement, but the current behavior is very painful

Steps to Reproduce

In a fresh directory I did

$ yarn
$ yarn add --dev jest react-scripts

Then I created a src/test.test.js files with the following content:

test("I'm asynchronous", async () => {
  const promise = Promise.reject("boom!")

  expect("some precondition").toBeFalsy()

  await rejected(promise)

  expect("some postcondition").toBeTruthy()
})

async function rejected(promise) {
  try {
      await promise
  } catch (e) {
      return e
  }

  throw new Error('Expected promise to be rejected')
}

Finally I ran the test with

CI=true yarn run react-scripts test --env=jsdom

This test demonstrates a pattern we use to test failure cases of React component callbacks as well as POJOs that make asynchronous requests and it works pretty well except when the test fails before we're able to await (and catch) our promise.

Expected Behavior

The behavior I would like to see is the failure due to expect("some precondition").toBeFalsy(). This is the assertion testing the behavior I need to change in order to fix this test. I wouldn't mind seeing output either before or after this failure to the effect of "There was an unhandled rejection", but I really need to see the failure in order to actually fix this test.

Actual Behavior

The actual behavior is that I see

$ CI=true yarn run react-scripts test --env=jsdom
yarn run v0.27.5
warning package.json: No license field
$ "$PATH_TO_NODE_MODULES/.bin/react-scripts" "test"

$PATH_TO_NODE_MODULES/react-scripts/scripts/test.js:22
   throw err;
   ^
boom!
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

With a little searching I can find the place "boom!" is coming from, but even then I can't really get the test to fail on "some precondition" not being falsy.

Is there a better way to preserve test failures while still guarding against unhandled promise rejections?

I spent a little time hacking test.js to accumulate unhandled rejections, and was able to force the process to exit 1 and report unhandled rejections (by hooking into process.on("exit")) but Jest still reports success right before the failure output, which is confusing for both humans and WebStorm. Hopefully someone with more Jest knowledge can come up with something better.

Please let me know if there's more information that would be helpful, or if there are better patterns that avoid this problem entirely.

Thanks!

Assignee
Assign to
Time tracking