summaryrefslogtreecommitdiff
path: root/test/parallel/test-stream-pipe-await-drain.js
AgeCommit message (Collapse)Author
2019-08-26stream: fix readable state `awaitDrain` increase in recursionran
PR-URL: https://github.com/nodejs/node/pull/27572 Reviewed-By: Anna Henningsen <anna@addaleax.net>
2018-11-27test: use arrow functions in callbacksapoorvanand
PR-URL: https://github.com/nodejs/node/pull/24441 Reviewed-By: Michaƫl Zasso <targos@protonmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
2018-06-08test: improve assert error messagesHristijan Gjorgjievski
Improve the assert error message so it includes actual value in the error message. PR-URL: https://github.com/nodejs/node/pull/21160 Reviewed-By: Weijia Wang <starkwang@126.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Yuta Hiroto <hello@hiroppy.me> Reviewed-By: Trivikram Kamat <trivikr.dev@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-18test: tests for _readableStream.awaitDrainMark
Fixes: https://github.com/nodejs/node/issues/8684 PR-URL: https://github.com/nodejs/node/pull/8914 Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
2016-04-11stream: Fix readableState.awaitDrain mechanismAnna Henningsen
In 68990948fe4 (https://github.com/nodejs/node/pull/2325), the conditions for increasing `readableState.awaitDrain` when writing to a piping destination returns false were changed so that they could not actually be met, effectively leaving `readableState.awaitDrain` with a constant value of 0. This patch changes the conditions to testing whether the stream for which `.write()` returned false is still a piping destination, which was likely the intention of the original patch. Fixes: https://github.com/nodejs/node/issues/5820 Fixes: https://github.com/nodejs/node/issues/5257 PR-URL: https://github.com/nodejs/node/pull/6023 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>