-
Notifications
You must be signed in to change notification settings - Fork 30k
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
test: add regex to assert in test_cyclic_link_protection #11498
Conversation
test/parallel/test-fs-realpath.js
Outdated
@@ -201,9 +201,11 @@ function test_cyclic_link_protection(callback) { | |||
fs.symlinkSync(t[1], t[0], 'dir'); | |||
unlink.push(t[0]); | |||
}); | |||
assert.throws(function() { fs.realpathSync(entry); }); | |||
assert.throws(function() { fs.realpathSync(entry); }, /^Error: ELOOP/); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use common.expectError(undefined, Error, 'ELOOP
)` here I believe. (Or some variation on that)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually... common.expectsError('ELOOP', Error')
should work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One downside to common.expectsError()
is that it increases the abstractions people have to learn about in order to work with even simple tests. Whereas before, all they had to know about is assert.throws()
, now they have to also know about common.expectsError()
. This is very different (IMO) from common.mustCall()
in that the latter has an intuitively understandable name, accepts arguments as one would expect, and (in most cases) doesn't actually require reading documentation or code to figure out what it's doing. With common.expectsError()
, there's a fair bit of magic. Like, it's not obvious what the first argument would be. Or the second. Or the third. You just have to know.
For that reason, I'm inclined to accept (encourage even) people submitting first PRs that add a regexp as a second argument to assert.throws()
calls that previously only had a single argument. Changing the regexp to common.expectsError()
can be their second PR or a subsequent PR from someone else.
One thing that might help is if the arguments accepted by common.expectsError()
were a single settings object. Someone coming across this has a hope of understanding what's going on without reading source or docs:
const validatorFunction = common.expectsError({code: 'ELOOP',
type: Error,
message: 'looped doodad found'});
This, by comparison, is harder to grok:
const validatorFunction = common.expectsError('ELOOP',
Error,
'looped doodad found');
And this is especially wat-inducing:
common.expectsError(undefined, undefined, 'looped doodad found');
It's likely that only people who work with tests frequently can be expected to remember the three arguments and their order. By comparison, remembering that the error code is code
and the message is message
might be manageable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'm spinning up a PR for the proposed API change right now.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing that might help is if the arguments accepted by common.expectsError() was a single settings object.
Yeah that looks way easier to understand (as someone who hasn't yet gotten round to reading the source or docs for common.expectsError()
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test/parallel/test-fs-realpath.js
Outdated
@@ -201,9 +201,11 @@ function test_cyclic_link_protection(callback) { | |||
fs.symlinkSync(t[1], t[0], 'dir'); | |||
unlink.push(t[0]); | |||
}); | |||
assert.throws(function() { fs.realpathSync(entry); }); | |||
assert.throws(function() { fs.realpathSync(entry); }, /^Error: ELOOP/); | |||
asynctest(fs.realpath, [entry], callback, function(err, result) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would likely be worthwhile to wrap the function(err, result) {}
block in a common.mustCall()
throughout as an extra check
@clarenced ... can you rebase this on the current master to avoid the extraneous commits? |
@jasnell Sorry I have made the same mistake again, I forgot to rebase on |
@clarenced I was able to fix it by rebasing against upstream/master, resolving a merge conflict, and force-pushing to your branch. You're all set for the moment, I think. (In the future, it would be a good idea to not use your master branch for development but to instead create a separate branch where development occurs.) |
}, common.expectsError({ code: 'ELOOP', type: Error })); | ||
asynctest( | ||
fs.realpath, [entry], callback, common.mustCall(function(err, result) { | ||
assert.ok(err.path === entry); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you use assert.strictEqual()
here and in the line below:
assert.strictEqual(err.path, entry);
assert.strictEqual(result, undefined);
That will provide better error messages should the assertion fire.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@clarenced I should have probably mentioned that you'll want to update from the force-pushed branch in a way that won't create a merge commit on your branch. Many ways to do it, here's one: git checkout master
git reset --hard ec4440a
git pull (That |
Closing in favor of #11622 |
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test