summaryrefslogtreecommitdiff
path: root/test/parallel/test-process-getactiverequests.js
AgeCommit message (Collapse)Author
2018-11-11test: fix args order in process-getactiverequestsVladyslav Kopylash
PR-URL: https://github.com/nodejs/node/pull/24186 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
2017-07-03test: remove common.noopRich Trott
This change removes `common.noop` from the Node.js internal testing common module. Over the last few weeks, I've grown to dislike the `common.noop` abstraction. First, new (and experienced) contributors are unaware of it and so it results in a large number of low-value nits on PRs. It also increases the number of things newcomers and infrequent contributors have to be aware of to be effective on the project. Second, it is confusing. Is it a singleton/property or a getter? Which should be expected? This can lead to subtle and hard-to-find bugs. (To my knowledge, none have landed on master. But I also think it's only a matter of time.) Third, the abstraction is low-value in my opinion. What does it really get us? A case could me made that it is without value at all. Lastly, and this is minor, but the abstraction is wordier than not using the abstraction. `common.noop` doesn't save anything over `() => {}`. So, I propose removing it. PR-URL: https://github.com/nodejs/node/pull/12822 Reviewed-By: Teddy Katz <teddy.katz@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Refael Ackermann <refack@gmail.com>
2017-03-26test: add common.noop, default for common.mustCall()James M Snell
Export a new common.noop no-operation function for general use. Allow using common.mustCall() without a fn argument to simplify test cases. Replace various non-op functions throughout tests with common.noop PR-URL: https://github.com/nodejs/node/pull/12027 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Teddy Katz <teddy.katz@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
2017-01-11test: s/assert.equal/assert.strictEqual/Gibson Fahnestock
Use assert.strictEqual instead of assert.equal in tests, manually convert types where necessary. PR-URL: https://github.com/nodejs/node/pull/10698 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Michaƫl Zasso <targos@protonmail.com> Reviewed-By: Teddy Katz <teddy.katz@gmail.com>
2015-12-26test: remove unnecessary assignmentsRich Trott
common.js needs to be loaded in all tests so that there is checking for variable leaks and possibly other things. However, it does not need to be assigned to a variable if nothing in common.js is referred to elsewhere in the test. PR-URL: https://github.com/nodejs/node/pull/4408 Reviewed-By: James M Snell <jasnell@gmail.com>
2015-10-21node: improve GetActiveRequests performanceTrevor Norris
v8 is faster at setting object properties in JS than C++. Even when it requires calling into JS from native code. Make process._getActiveRequests() faster by doing this when populating the array containing request objects. Simple benchmark: for (let i = 0; i < 22; i++) fs.open(__filename, 'r', function() { }); let t = process.hrtime(); for (let i = 0; i < 1e6; i++) process._getActiveRequests(); t = process.hrtime(t); console.log((t[0] * 1e9 + t[1]) / 1e6); Results between the two: Previous: 4406 ns/op Patched: 690 ns/op 5.4x faster PR-URL: https://github.com/nodejs/node/pull/3375 Reviewed-By: James Snell <jasnell@gmail.com> Reviewed-By: Ben Noordhuis <ben@strongloop.com>