Skip to content

Commit 42ac03c

Browse files
committed
Reorder mux test because 'readable' event deferred
The behaviour of the `'readable'` event changed, or was tightened up, in nodejs/node#17979 such that it is _always_ called on the next tick. This change appears first in Node.JS v10.0). Since we rely on `'readable' in the multiplexing, it means that we have to be more careful about when we wait for the next event loop to come around in tests. The tests tend to be much more brittle than live code with respect to the order things happen, since they attempt to nail down precise states or orderings (e.g., "the `unpipe` happened exactly between these writes").
1 parent cdc8d33 commit 42ac03c

File tree

1 file changed

+10
-6
lines changed

1 file changed

+10
-6
lines changed

test/mux.js

+10-6
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ test("single input", function(done) {
3737
var mux = new Mux(output);
3838
mux.pipeFrom(input);
3939

40-
var data = [1,2,3,4,5,6,7,8,9];
40+
var data = [1,2,3,4,5,6,7,8,9];
4141
// not 0, it's treated specially by PassThrough for some reason. By
4242
// 'specially' I mean it breaks the stream. See e.g.,
4343
// https://github.com/isaacs/readable-stream/pull/55
@@ -112,16 +112,20 @@ test("unpipe", function(done) {
112112

113113
schedule(function() {
114114
pipedData.forEach(input.write.bind(input));
115-
mux.unpipeFrom(input);
116115

117116
schedule(function() {
118-
unpipedData.forEach(input.write.bind(input));
119-
input.end();
117+
mux.unpipeFrom(input);
118+
120119
schedule(function() {
121-
// exhaust so that 'end' fires
122-
var v; while (v = input.read());
120+
unpipedData.forEach(input.write.bind(input));
121+
input.end();
122+
schedule(function() {
123+
// exhaust so that 'end' fires
124+
var v; while (v = input.read());
125+
});
123126
});
124127
});
128+
125129
});
126130

127131
input.on('end', function() {

0 commit comments

Comments
 (0)