test: replace indexOf with includes
#13215
Conversation
| @@ -55,7 +55,8 @@ function request(i) { | |||
| socket.on('close', function() { | |||
| ++count; | |||
| if (count < max) { | |||
| assert.strictEqual(http.globalAgent.sockets[name].indexOf(socket), -1); | |||
| assert.strictEqual(http.globalAgent.sockets[name].includes(socket), | |||
There was a problem hiding this comment.
I like this approach 👍
More literal then assert.ok(!...
| expectedHeaders[req.method].indexOf(header.toLowerCase()), | ||
| -1, | ||
| expectedHeaders[req.method].includes(header.toLowerCase()), | ||
| false, |
There was a problem hiding this comment.
Could we change assert.notStrictEqual(..., false, ...) -> assert.strictEqual(..., true, ...)? The double negative seems unnecessary now.
There was a problem hiding this comment.
Ah missed that! Will fix it!
Also @gibfahn , why doesn't assert provide a functions like assertFalse ?
(Similar to assertok )
There was a problem hiding this comment.
We have assert.fail() to test if something is falsy, but it's not a strict comparison (it's == not ===), and I find the assertStrictEqual(..., false) more clear (not sure why we have assert.fail not assert.false).
Replaced `indexOf` with `includes` in test-http-client-agent, test-http-client-default-headers-exist Refs: nodejs#12586
PR-URL: nodejs#13215 Refs: nodejs#12586 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
|
Landed in 9c64278 |
|
Post land CI: https://ci.nodejs.org/job/node-test-commit/10197/ |
PR-URL: #13215 Refs: #12586 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
|
I have mixed feelings in backporting this to v6.x. @nodejs/v8 is this something we need to be concerned about from a performance standpoint? If the change is fairly moot in 8.x, but causes problems on 6.x, I'm not convinced the churn is worth it (as it will make backporting harder). I would appreciate if this type of research could be done before landing these changes wholesale. If this has already been researched and it is a non issue please accept my humble apologies for crankiness in the above paragraph 😄 |
This was discussed re backporting in #12586 (comment) and was "empirically" tested for compatibility. Hope this info helps. |
As @refack says, only I assume we'd plan to wait till v6.x goes into maintenance before considering changes to
We did discuss this in an LTS meeting: #12586 (comment) and https://github.com/nodejs/LTS/blob/master/doc/meetings/2017-04-24.md#backporting-test-fixes-to-maintenance-branches-205
Sounds like backporting induced PTSD to me 😁 |
|
PR-URL: #13215 Refs: #12586 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
PR-URL: #13215 Refs: #12586 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
Refs: #12586
Tests Updated:
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
test