-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
[v12.x backport] test: refactor common.expectsError #31449
Conversation
https://ci.nodejs.org/job/node-test-commit-linux/nodes=centos7-64-gcc6/32389/consoleFull (Thanks @BethGriggs for kicking it off) failed the PR test job due to the failure shown below with
|
44a6565
to
9f59f39
Compare
All comments addressed @BridgeAR if you want to take another look. |
This passed although doesn't include my latest (minor) tweak to address review comments |
9f59f39
to
a7afcbb
Compare
I've rebased against v12.x to fixed conflicts. |
67ec97a
to
fc7b27e
Compare
a01fb4a
to
e5dc2fb
Compare
63a03d2
to
d577190
Compare
This completely refactors the `expectsError` behavior: so far it's almost identical to `assert.throws(fn, object)` in case it was used with a function as first argument. It had a magical property check that allowed to verify a functions `type` in case `type` was passed used in the validation object. This pattern is now completely removed and `assert.throws()` should be used instead. The main intent for `common.expectsError()` is to verify error cases for callback based APIs. This is now more flexible by accepting all validation possibilites that `assert.throws()` accepts as well. No magical properties exist anymore. This reduces surprising behavior for developers who are not used to the Node.js core code base. This has the side effect that `common` is used significantly less frequent. Backport-PR-URL: nodejs#31449 PR-URL: nodejs#31092 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
rebased |
This completely refactors the `expectsError` behavior: so far it's almost identical to `assert.throws(fn, object)` in case it was used with a function as first argument. It had a magical property check that allowed to verify a functions `type` in case `type` was passed used in the validation object. This pattern is now completely removed and `assert.throws()` should be used instead. The main intent for `common.expectsError()` is to verify error cases for callback based APIs. This is now more flexible by accepting all validation possibilites that `assert.throws()` accepts as well. No magical properties exist anymore. This reduces surprising behavior for developers who are not used to the Node.js core code base. This has the side effect that `common` is used significantly less frequent. Backport-PR-URL: #31449 PR-URL: #31092 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
landed in d568efc |
Thanks @MylesBorins - I hadn't got back to doing the rebase after the release went out as it looked rather non-trivial to redo with the modified history on this one, but should be a good one to get in. |
@sxa555 it is landed and in! FWIW I made a new branch off of staging and cherry-picked your initial commit (rather than rebasing). There was only a single conflict, so it was rather straight forward all things considered |
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesEver had one of those moments when you wish you hadn't started a backport but wanted to see it through to completion? I'm glad this is done now and it'll definitely make subsequent backports easer (would have helped for the other one I did this evening). Understandable there are quite a few adjustments in this due to differences in test cases between v12.x and master which meant that many fixups were required, but this now passes the tests.
I've only verified that this is ok on xLinux.
If someone can kick off the test-commit job that would be appreciated.
For reviewers, it's probably fairly obvious but the "fixup" commit in here contains most of the changes I had to make manually (plus a couple of typo fixes from my first merge resolution)