-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Conversation
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.
LGTM if CI is ✅. /cc @nodejs/testing
mixedByteStringUcs2.includes(Buffer.from('bc', 'ucs2'), 0, 'ucs2')); | ||
assert.ok( | ||
mixedByteStringUcs2.includes(Buffer.from('\u03a3', 'ucs2'), 0, 'ucs2')); | ||
assert.ifError( |
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: I would use assert.ok(!...)
for consistency and proper thrown error in case of failure
aaf7a0a
to
9e040a1
Compare
Updated the PR to address @lpinca's feedback. |
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 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
9e040a1
to
b9977cf
Compare
@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. |
Failed tests on CentOS 5:
and on Windows:
are unrelated to this PR, but it think we should investigate those tests. Troubles on test/arm-fanned (pi1-raspbian-wheezy):
|
@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 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(); |
@aqrln |
The built-in indent rule doesn't check for this, but we could probably make a custom rule for it if we wanted to. |
@gibfahn I think we can lint that run-on lines are indented with at least four spaces. That should cover both cases. |
|
@gibfahn is the |
That was probably a mistake. I changed the label. |
CI failures are unrelated |
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]>
Landed in 52b666e |
@aqrln
EDIT: nodejs/node-review#9 has landed, so we should be good going forward! |
@gibfahn okay, thanks for clarifying this. |
This was standardised in nodejs/node#10670. Refs: nodejs/node#12040
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]>
This was standardised in nodejs/node#10670. Refs: nodejs/node#12040
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]>
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]>
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]>
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:
buffer.includes()
was supposed to return the same value thatbuffer.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 ofassert.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()
andassert.ifError()
and removes redundant indices.Refs: #3567
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test