-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unhandled promise rejection in async tests #2797
Comments
We have #2640 for the unhandled rejection detection, for what it's worth. (Closing this as a duplicate of that as far as resolution on Mocha's end, but feel free to discuss your particular case here further as needed.) However, the caveat I mentioned there applies here: the function named To address this specific case in more detail:
The const assert = require('assert');
describe('test', () => {
it('should function properly', done => {
new Promise((resolve, reject) => reject(new Error('aw snap!')))
//.then will never be called from the rejected promise
.catch(err => { // this handles the `new Error` rejection above
assert.equal(err.message, 'oops!'); // this may throw
done();
}); // this promise may now be rejected with an assertion error thrown out of the catch block
// because promise is neither returned nor used further, if it ended up rejected then that's unhandled
});
});
Well, there is, it's just never leaving the function in which it's created... which at least partly defeats the purpose of using promises instead of callbacks: they're intended to give us back the ability to handle errors in the caller's scope (among other design patterns from synchronous programming). A couple unrelated promise programming tips:
|
Thank you for the very detailed explanation! It completely makes sense that calling This came up refactoring an existing callback-based service to integrate with some new promise-based code. I think for now I'll keep the unhandledRejection handler there in the test code and make absolutely sure the code path after cb can't throw. I suppose it would make sense to rework the entire code path to use promises... no half measures, Walt |
Hello, Could you please let me know how can I implement cases when is expected that promise should be rejected and contain 'my_message' message? |
function(args).catch((err) => { |
@martin-ayvazyan13, please open a new issue... |
Before, the assertion failure that mocha could readily interpret was wrapped when inside an async hook. This made for very not helpful failures. This unwraps to prevent this. See mochajs/mocha#2797
Before, the assertion failure that mocha could readily interpret was wrapped when inside an async hook. This made for very not helpful failures. This unwraps to prevent this. See mochajs/mocha#2797
I can't seem to get this to work. If a routine under test uses promises at some point and catches any errors returning the result to the callback function, it's not possible to throw assertion exceptions in the test code without resulting in an unhandled promise rejection and the test timing out
Consider the following:
Results in:
I don't understand why the
assert.equal
throw isn't handled - the only promise in play here is in thetest
function and it is handled and returns the error to the first parameter of cb properly. I would call catch on the promise in the test code, but as far as I can tell there is no promise to attach a catch to!To get this to work, I need to wrap assertion code in a try/catch and call
done
with the error if one is encountered.... which is not ideal.Or, attach a event handler for unhandledRejection on process which, again, is not ideal
Is there a reason mocha doesn't do this itself, i.e.:
With that modified directly in the
node_modules
directory everything works as expected.The text was updated successfully, but these errors were encountered: