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: fix broken tests in test-buffer-includes #12040

Closed
wants to merge 1 commit into from

Conversation

aqrln
Copy link
Contributor

@aqrln aqrln commented Mar 25, 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 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-bot nodejs-github-bot added the test Issues and PRs related to the tests. label Mar 25, 2017
Copy link
Member

@Trott Trott left a comment

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

@mscdex mscdex added the buffer Issues and PRs related to the buffer subsystem. label Mar 26, 2017
mixedByteStringUcs2.includes(Buffer.from('bc', 'ucs2'), 0, 'ucs2'));
assert.ok(
mixedByteStringUcs2.includes(Buffer.from('\u03a3', 'ucs2'), 0, 'ucs2'));
assert.ifError(
Copy link
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
Copy link
Contributor Author

aqrln commented Mar 26, 2017

Updated the PR to address @lpinca's feedback.

Copy link
Contributor

@cjihrig cjihrig left a comment

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
Copy link
Contributor Author

aqrln commented Mar 26, 2017

@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
Member

hiroppy commented Mar 26, 2017

@aqrln
Copy link
Contributor Author

aqrln commented Mar 26, 2017

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
Member

gibfahn commented Mar 26, 2017

@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
Copy link
Member

gibfahn commented Mar 26, 2017

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

@not-an-aardvark
Copy link
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
Contributor Author

aqrln commented Mar 26, 2017

@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
Contributor Author

aqrln commented Mar 27, 2017

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

@aqrln
Copy link
Contributor Author

aqrln commented Mar 27, 2017

@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
Member

targos commented Mar 27, 2017

That was probably a mistake. I changed the label.

@jasnell
Copy link
Member

jasnell commented Mar 27, 2017

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 <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Yuta Hiroto <[email protected]>
Reviewed-By: Santiago Gimeno <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@jasnell
Copy link
Member

jasnell commented Mar 27, 2017

Landed in 52b666e

@jasnell jasnell closed this Mar 27, 2017
@aqrln aqrln deleted the fix-test-buffer-includes branch March 27, 2017 17:33
@aqrln
Copy link
Contributor Author

aqrln commented Mar 28, 2017

@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
Copy link
Member

gibfahn commented Mar 28, 2017

@aqrln Ref 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
Contributor Author

aqrln commented Mar 28, 2017

@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 <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Yuta Hiroto <[email protected]>
Reviewed-By: Santiago Gimeno <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Mar 28, 2017
evanlucas pushed a commit to nodejs/node-review that referenced this pull request Mar 29, 2017
@italoacasas italoacasas 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 <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Yuta Hiroto <[email protected]>
Reviewed-By: Santiago Gimeno <[email protected]>
Reviewed-By: James M Snell <[email protected]>
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 <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Yuta Hiroto <[email protected]>
Reviewed-By: Santiago Gimeno <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@MylesBorins MylesBorins 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 <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Yuta Hiroto <[email protected]>
Reviewed-By: Santiago Gimeno <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
buffer Issues and PRs related to the buffer subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.