Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: remove duplicate test about warning in lib/net.js #41307
test: remove duplicate test about warning in lib/net.js #41307
Changes from 1 commit
7fa3e4e
c23d0e6
2045739
6ef49ff
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
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.
nit: this could be simplified as
mustCall
will check that the callback is only invoked once. We can also explicitly provide the number of calls we are expecting so it's clearer: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.
@aduh95 Your suggestion is simpler, but is slightly more permissive than the code in this PR. The code in this PR guarantees that the first call of the API results in a warning and the second call does not. The change you suggest here will still result in a passing test if the first call does not result in a warning and the second one does. Admittedly, that's an edge case that is unlikely to happen. But I have a slight preference for the stricter checking here.
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 don’t see how, the current code checks the
'warning'
event is emitted once, but I don’t think it can know what API call triggered it either 🤔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.
Current code in master branch tests it by having two separate tests that are nearly identical. One test only calls the API once and makes sure that the warning is emitted once. The other test calls the API twice and makes sure that the warning is emitted once. Alone, that second test doesn't confirm that the warning happens on the first API call, but in combination with the first test, that is effectively checked.
This PR consolidates those two tests into a single test.
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.
Oh, wait, or are you suggesting that there will be a problem if something else (like
--pending-deprecations
) causes warnings? Yeah, that's a valid concern and one we should address....I'm wondering if we're actually best off just having two tests. :-D
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.
@kuriyosh How would you feel about restoring both tests and adding a short comment in each one explaining why there are two different-but-very-similar tests?
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.
In my understanding, the discussed concern is that this test fails if other warnings occur in a second call. (Please point me out if I'm wrong here.) I agree that we need to run
test-net-deprecated-setsimultaneousaccepts.js
to make sure that_setSimultaneousAccepts()
does not emit other warnings.On the other hand,
test-net-server-simultaneous-accepts-produce-warning-once.js
in master branch does not check whether if_setSimultaneousAccepts()
emitDEP0121
in a second call. That test can be passed if second calling_setSimultaneousAccepts()
emitDEP0121
because of the behavior of expectsWarning().So, I think the change of
test-net-server-simultaneous-accepts-produce-warning-once.js
in this PR is needed.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 does check.
expectsWarning()
will fail if it receives the warning more than once.This exits with a failure status:
This exits with success status:
And this exits with a failure status again:
One thing I notice while running these tests is that the error message is not great on that last example because
const [ message, code ] = expected.shift();
(intest/common/index.js
) does not accommodate the possibility thatexpected
is an empty array andexpected.shift()
returnsundefined
:So that's probably worth fixing.
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.
#41326
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.
Sorry, I misunderstood the behavior of
expectWarning
...I totally agree on having two separate tests.
I have committed for adding comment in these test codes.