Skip to content

test: fix broken tests in test-buffer-includes - #12040

Closed
aqrln wants to merge 1 commit into
nodejs:masterfrom
aqrln:fix-test-buffer-includes
Closed

test: fix broken tests in test-buffer-includes#12040
aqrln wants to merge 1 commit into
nodejs:masterfrom
aqrln:fix-test-buffer-includes

Conversation

@aqrln

Copy link
Copy Markdown
Contributor

Some of the tests for buffer.includes() functionality introduced in #3567 have been broken in a way that caused them to always pass regardless of the result of the tested method.

This behavior was caused by two reasons:

  • These tests were written as though buffer.includes() was supposed to return the same value that buffer.indexOf() does, i.e., used indices or -1 as expected return values instead of true and false.
  • assert() was used as the assertion function to do that instead of assert.strictEqual().

Thus assert() was called with a non-zero number as the first argument effectively causing these tests to pass.

This commit changes the tests to use assert.ok() and assert.ifError() and removes redundant indices.

Refs: #3567

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

test

@nodejs-github-botnodejs-github-bot added the test Issues and PRs related to the tests. label Mar 25, 2017

@TrottTrott left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM if CI is ✅. /cc @nodejs/testing

@mscdexmscdex added the buffer Issues and PRs related to the buffer subsystem. label Mar 26, 2017

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I would use assert.ok(!...) for consistency and proper thrown error in case of failure

@aqrln
aqrlnforce-pushed the fix-test-buffer-includes branch from aaf7a0a to 9e040a1CompareMarch 26, 2017 15:25
@aqrln

Copy link
Copy Markdown
ContributorAuthor

Updated the PR to address @lpinca's feedback.

@cjihrigcjihrig left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can never remember if the indentation should be two or four spaces in these cases, but it looks like this PR uses both. Could you pick one or the other. Other than that, LGTM.

Some of the tests for `buffer.includes()` functionality introduced in
nodejs#3567 have been broken in a way that
caused them to always pass regardless of the result of the tested
method.
This behavior was caused by two reasons:
* These tests were written as though `buffer.includes()` was supposed
to return the same value that `buffer.indexOf()` does, i.e., used
indices or -1 as expected return values instead of true and false.
* `assert()` was used as the assertion function to do that instead of
`assert.strictEqual()`.
Thus `assert()` was called with a non-zero number as the first argument
effectively causing these tests to pass.
This commit changes the tests to use `assert.ok()` and removes redundant
indices.
Refs: nodejs#3567
@aqrln
aqrlnforce-pushed the fix-test-buffer-includes branch from 9e040a1 to b9977cfCompareMarch 26, 2017 16:15
@aqrln

Copy link
Copy Markdown
ContributorAuthor

@cjihrig thanks for catching that, the PR has been updated. I've chosen four for this commit because it is more common throughout the file, but it is not consistent even in existing code. I guess I'll open a new PR that fixes the code style in this file.

@hiroppy

Copy link
Copy Markdown
Member

@aqrln

aqrln commented Mar 26, 2017

Copy link
Copy Markdown
ContributorAuthor

Failed tests on CentOS 5:

  • parallel/test-dns-regress-6244
  • parallel/test-net-connect-options-ipv6

and on Windows:

  • parallel/test-child-process-exec-kill-throws

are unrelated to this PR, but it think we should investigate those tests.

Troubles on test/arm-fanned (pi1-raspbian-wheezy):

java.io.IOException: Failed to create a temp file on /home/iojs/build/workspace/node-test-binary-arm
java.io.IOException: No space left on device

@gibfahn

Copy link
Copy Markdown
Member

@cjihrig I think it's 4 spaces for run-on lines, so that if you have:

while("Some really really really really really long string"===somethingElse.toString())doThis();

The somethingElse.toString() is clearly separate from the doThis().

Seems like something that should be in the STYLE_GUIDE though (except that the STYLE_GUIDE currently doesn't cover code), I assume we don't lint for it because sometimes we want visual linting, but I'm not sure (cc/ @not-an-aardvark, is this something that we could easily lint for)?

Visual linting:

while("Some really really really really really long string"===somethingElse.toString())doThis();

@gibfahn

gibfahn commented Mar 26, 2017

Copy link
Copy Markdown
Member

@aqrlnparallel/test-child-process-exec-kill-throws failure is unrelated to this PR, see #11038 (comment)

@not-an-aardvark

Copy link
Copy Markdown
Contributor

(cc/ @not-an-aardvark, is this something that we could easily lint for)?

The built-in indent rule doesn't check for this, but we could probably make a custom rule for it if we wanted to.

@aqrln

Copy link
Copy Markdown
ContributorAuthor

@gibfahn I think we can lint that run-on lines are indented with at least four spaces. That should cover both cases.

@aqrln

Copy link
Copy Markdown
ContributorAuthor

dont-land-on-v4.x and lts-watch-v6.x labels should be added, I suppose.

@aqrln

Copy link
Copy Markdown
ContributorAuthor

@gibfahn is the dont-land-on-v6.x label intentional? It cherry-picks cleanly to v6.x-staging but maybe I'm missing something.

@targos

Copy link
Copy Markdown
Member

That was probably a mistake. I changed the label.

@jasnell

Copy link
Copy Markdown
Member

CI failures are unrelated

jasnell pushed a commit that referenced this pull request Mar 27, 2017
Some of the tests for `buffer.includes()` functionality introduced in
#3567 have been broken in a way that
caused them to always pass regardless of the result of the tested
method.
This behavior was caused by two reasons:
* These tests were written as though `buffer.includes()` was supposed
to return the same value that `buffer.indexOf()` does, i.e., used
indices or -1 as expected return values instead of true and false.
* `assert()` was used as the assertion function to do that instead of
`assert.strictEqual()`.
Thus `assert()` was called with a non-zero number as the first argument
effectively causing these tests to pass.
This commit changes the tests to use `assert.ok()` and removes redundant
indices.
PR-URL: #12040
Ref: #3567
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@jasnell

Copy link
Copy Markdown
Member

Landed in 52b666e

@jasnelljasnell closed this Mar 27, 2017
@aqrln
aqrln deleted the fix-test-buffer-includes branch March 27, 2017 17:33
@aqrln

Copy link
Copy Markdown
ContributorAuthor

@jasnell btw, I see that you changed Refs: to Ref: in the commit message. I'm fine with both, but I thought Refs: was standardized in #10670.

@gibfahn

gibfahn commented Mar 28, 2017

Copy link
Copy Markdown
Member

@aqrlnRef is what node-review uses.

Ref: is still okay, we just suggest Refs: because it was used by more people.

EDIT:nodejs/node-review#9 has landed, so we should be good going forward!

@aqrln

Copy link
Copy Markdown
ContributorAuthor

@gibfahn okay, thanks for clarifying this.

gibfahn added a commit to gibfahn/node-review that referenced this pull request Mar 28, 2017
MylesBorins pushed a commit that referenced this pull request Mar 28, 2017
Some of the tests for `buffer.includes()` functionality introduced in
#3567 have been broken in a way that
caused them to always pass regardless of the result of the tested
method.
This behavior was caused by two reasons:
* These tests were written as though `buffer.includes()` was supposed
to return the same value that `buffer.indexOf()` does, i.e., used
indices or -1 as expected return values instead of true and false.
* `assert()` was used as the assertion function to do that instead of
`assert.strictEqual()`.
Thus `assert()` was called with a non-zero number as the first argument
effectively causing these tests to pass.
This commit changes the tests to use `assert.ok()` and removes redundant
indices.
PR-URL: #12040
Ref: #3567
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorinsMylesBorins mentioned this pull request Mar 28, 2017
evanlucas pushed a commit to nodejs/node-review that referenced this pull request Mar 29, 2017
@italoacasasitaloacasas mentioned this pull request Apr 10, 2017
2 tasks
MylesBorins pushed a commit that referenced this pull request Apr 18, 2017
Some of the tests for `buffer.includes()` functionality introduced in
#3567 have been broken in a way that
caused them to always pass regardless of the result of the tested
method.
This behavior was caused by two reasons:
* These tests were written as though `buffer.includes()` was supposed
to return the same value that `buffer.indexOf()` does, i.e., used
indices or -1 as expected return values instead of true and false.
* `assert()` was used as the assertion function to do that instead of
`assert.strictEqual()`.
Thus `assert()` was called with a non-zero number as the first argument
effectively causing these tests to pass.
This commit changes the tests to use `assert.ok()` and removes redundant
indices.
PR-URL: #12040
Ref: #3567
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit that referenced this pull request Apr 19, 2017
Some of the tests for `buffer.includes()` functionality introduced in
#3567 have been broken in a way that
caused them to always pass regardless of the result of the tested
method.
This behavior was caused by two reasons:
* These tests were written as though `buffer.includes()` was supposed
to return the same value that `buffer.indexOf()` does, i.e., used
indices or -1 as expected return values instead of true and false.
* `assert()` was used as the assertion function to do that instead of
`assert.strictEqual()`.
Thus `assert()` was called with a non-zero number as the first argument
effectively causing these tests to pass.
This commit changes the tests to use `assert.ok()` and removes redundant
indices.
PR-URL: #12040
Ref: #3567
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorinsMylesBorins mentioned this pull request Apr 19, 2017
andrew749 pushed a commit to michielbaird/node that referenced this pull request Jul 19, 2017
Some of the tests for `buffer.includes()` functionality introduced in
nodejs/node#3567 have been broken in a way that
caused them to always pass regardless of the result of the tested
method.
This behavior was caused by two reasons:
* These tests were written as though `buffer.includes()` was supposed
to return the same value that `buffer.indexOf()` does, i.e., used
indices or -1 as expected return values instead of true and false.
* `assert()` was used as the assertion function to do that instead of
`assert.strictEqual()`.
Thus `assert()` was called with a non-zero number as the first argument
effectively causing these tests to pass.
This commit changes the tests to use `assert.ok()` and removes redundant
indices.
PR-URL: nodejs/node#12040
Ref: nodejs/node#3567
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bufferIssues and PRs related to the buffer subsystem.testIssues and PRs related to the tests.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

14 participants

@aqrln@hiroppy@gibfahn@not-an-aardvark@targos@jasnell@Trott@addaleax@santigimeno@lpinca@cjihrig@mscdex@MylesBorins@nodejs-github-bot