Probably more of an enhancement, but the current behavior is very painful
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.
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.
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!
It seems like you'd get the best response to this in Jest repo: http://github.com/facebook/jest.
Hi @gaearon, could you elaborate on why this should move to Jest?
Naively, it seems like it's the test.js script that's causing the issue. Is it possible for Jest to handle the rejection when this code is immediately throwing? My initial experiments in that direction didn't seem promising -- the test.js hook throws before any other hooks I can set up.
Yeah I think you're probably right. We'll look at this, thanks for a small example.
I can't reproduce this on the next branch so this should be solved in 2.0 alphas coming out soon.
I'm not sure what fixed it and we probably won't be backporting the fix to 1.x.
I see a Node deprecation warning when running this test though, and I don't know whether it's safe to ignore. I raised https://github.com/facebook/jest/issues/5311 about this.
I'm also concerned about the behavior described in https://github.com/facebook/jest/issues/3251#issuecomment-337032314. I don't know if it's related to your issue or not, but I'll raise a separate issue to track this.
Most helpful comment
I can't reproduce this on the
nextbranch so this should be solved in 2.0 alphas coming out soon.I'm not sure what fixed it and we probably won't be backporting the fix to 1.x.
I see a Node deprecation warning when running this test though, and I don't know whether it's safe to ignore. I raised https://github.com/facebook/jest/issues/5311 about this.
I'm also concerned about the behavior described in https://github.com/facebook/jest/issues/3251#issuecomment-337032314. I don't know if it's related to your issue or not, but I'll raise a separate issue to track this.