Skip to content
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

assert.rejects can error if a fat-arrow function is used #1630

Closed
smcclure15 opened this issue Jul 2, 2021 · 0 comments · Fixed by #1635
Closed

assert.rejects can error if a fat-arrow function is used #1630

smcclure15 opened this issue Jul 2, 2021 · 0 comments · Fixed by #1635
Assignees
Labels
Type: Bug Something isn't working right.

Comments

@smcclure15
Copy link
Member

Tell us about your runtime:

  • QUnit version: 2.16.0
  • Which environment are you using? (e.g., browser, Node): Node
  • How are you running QUnit? (e.g., QUnit CLI, Grunt, Karma, manually in browser): CLI

When the reject "reason" is a string, both function handlers and "fat-arrow" functions work well (both of these pass):

QUnit.test('String reason, function handler', assert => {
    let p = Promise.reject('reason');
    assert.rejects(p, function(err) {
        return err.toString().includes('reason');
    });
});
QUnit.test('String reason, arrow handler', assert => {
    let p = Promise.reject('reason');
    assert.rejects(p, err => {
        return err.toString().includes('reason');
    });
});
TAP version 13
ok 1 String reason, function handler
ok 2 String reason, arrow handler
1..2
# pass 2
# skip 0
# todo 0
# fail 0

However, when the "reason" is an Error object, the function handlers work well, but the fat-arrow's do not:

QUnit.test('Error reason, function handler', assert => {
    let p = Promise.reject(new Error('reason'));
    assert.rejects(p, function(err) {
        return err.toString().includes('reason');
    });
});
QUnit.test('Error reason, arrow handler, sync', assert => {
    let p = Promise.reject(new Error('reason'));
    assert.rejects(p, err => {
        return err.toString().includes('reason');
    });
});
QUnit.test('Error reason, arrow handler, async', async assert => {
    let p = Promise.reject(new Error('reason'));
    await assert.rejects(p, err => {
        return err.toString().includes('reason');
    });
});

If I run that as written, I see

TAP version 13
ok 1 Error reason, function handler
Error: Process exited before tests finished running
Last test to run (Error reason, arrow handler, sync) has an async hold. Ensure all assert.async() callbacks are invoked and Promises resolve. You should also set a standard timeout via QUnit.config.testTimeout.

So it barfed on the second test. If I skip the second one, I get:

TAP version 13
ok 1 Error reason, function handler
ok 2 # SKIP Error reason, arrow handler, sync
not ok 3 Error reason, arrow handler, async
  ---
  message: "Promise rejected during \"Error reason, arrow handler, async\": Function has non-object prototype 'undefined' in instanceof check"
  severity: failed
  actual  : null
  expected: undefined
  stack: |
    TypeError: Function has non-object prototype 'undefined' in instanceof check
        at Function.[Symbol.hasInstance] (<anonymous>)
  ...
1..3
# pass 1
# skip 1
# todo 0
# fail 1

I'm not sure if that sync/async behavior is related, or is a separate issue.

The error message is reminiscent of #1389, and likely a similar fix should resolve it.

@Krinkle Krinkle added the Type: Bug Something isn't working right. label Jul 2, 2021
Krinkle pushed a commit that referenced this issue Jul 26, 2021
…rejects()`

Validation and matching are now the same between `assert.throws` and `assert.rejects`.
This fixed the inability to use arrow functions with `rejects()`, as previously fixed for `throws()`, #1630.
This also (temporarily) loosens `assert.rejects` to tolerate and silently ignore all falsey expected value.
We'll deprecate that for both methods in a follow-up.

Non-function values passed as block to assert.throws() now result in a simulated assertion
failure with descriptive error message, instead of previously where we failed via `block.call()`
throwing a TypeError which the user presumably would not have been (wanting to be) matching.
This fixes #1637.

Fixes #1630.
Fixes #1637.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Something isn't working right.
Development

Successfully merging a pull request may close this issue.

2 participants