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

test: remove common.getServiceName() #6709

Closed
wants to merge 1 commit into from
Closed

Conversation

Trott
Copy link
Member

@Trott Trott commented May 12, 2016

Checklist
  • tests and code linting passes
  • the commit message follows commit guidelines
Affected core subsystem(s)

test dns

Description of change

Replace lightly-used services file parsing in favor of
confirming one of a small number of allowable values in service name
lookup tests.

In nodejs/node-v0.x-archive#8047, it was
decided that this sort of service file parsing was superior to
hardcoding acceptable values, but I'm not convinced:

  • No guarantee that the host uses /etc/services before, e.g., nscd.
  • Increases complexity of tests without guaranteeing robustness.

I think that simply checking against a small set of expected values
may be a better solution. Ideally, there would also be a unit test that
used a test double for the appropriate cares function and confirms
that it is called with the correct parameters, but now we're getting way
ahead of ourselves.

@nodejs/test @nodejs/build @misterdjules

@Trott Trott added dns Issues and PRs related to the dns subsystem. test Issues and PRs related to the tests. labels May 12, 2016
Replace lightly-used services file parsing in favor of
confirming one of a small number of allowable values in service name
lookup tests.

In nodejs/node-v0.x-archive#8047, it was
decided that this sort of service file parsing was superior to
hardcoding acceptable values, but I'm not convinced:

* No guarantee that the host uses /etc/services before, e.g., nscd.
* Increases complexity of tests without guaranteeing robustness.

I think that simply checking against a small set of expected values
may be a better solution. Ideally, there would also be a unit test that
used a test double for the appropriate `cares` function and confirms
that it is called with the correct parameters, but now we're getting way
ahead of ourselves.
@bnoordhuis
Copy link
Member

LGTM

2 similar comments
@jasnell
Copy link
Member

jasnell commented May 12, 2016

LGTM

@cjihrig
Copy link
Contributor

cjihrig commented May 13, 2016

LGTM

@Trott
Copy link
Member Author

Trott commented May 14, 2016

@Trott
Copy link
Member Author

Trott commented May 14, 2016

One failure on CI but it is unrelated. Opened an issue for that and will land this momentarily...

Trott added a commit to Trott/io.js that referenced this pull request May 14, 2016
Replace lightly-used services file parsing in favor of
confirming one of a small number of allowable values in service name
lookup tests.

In nodejs/node-v0.x-archive#8047, it was
decided that this sort of service file parsing was superior to
hardcoding acceptable values, but I'm not convinced:

* No guarantee that the host uses /etc/services before, e.g., nscd.
* Increases complexity of tests without guaranteeing robustness.

I think that simply checking against a small set of expected values
may be a better solution. Ideally, there would also be a unit test that
used a test double for the appropriate `cares` function and confirms
that it is called with the correct parameters, but now we're getting way
ahead of ourselves.

PR-URL: nodejs#6709
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@Trott
Copy link
Member Author

Trott commented May 14, 2016

Landed in 1a0c80a

@Trott Trott closed this May 14, 2016
evanlucas pushed a commit that referenced this pull request May 17, 2016
Replace lightly-used services file parsing in favor of
confirming one of a small number of allowable values in service name
lookup tests.

In nodejs/node-v0.x-archive#8047, it was
decided that this sort of service file parsing was superior to
hardcoding acceptable values, but I'm not convinced:

* No guarantee that the host uses /etc/services before, e.g., nscd.
* Increases complexity of tests without guaranteeing robustness.

I think that simply checking against a small set of expected values
may be a better solution. Ideally, there would also be a unit test that
used a test double for the appropriate `cares` function and confirms
that it is called with the correct parameters, but now we're getting way
ahead of ourselves.

PR-URL: #6709
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@Trott Trott deleted the pedestrian branch January 13, 2022 22:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dns Issues and PRs related to the dns subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants