#2933. Add tests for Stream.multi constructor.

[sgrekhov]

No description provided.

[lrhn]

Are there tests for the MultiStreamController API? Which is the normal StreamController API plus addSync, addErrorSync and closeSync, which allows adding events synchronously (after listen has returned, not paused, and if there are no prior events still enqueued).

[sgrekhov]

Updated. PTAL.

Are there tests for the MultiStreamController API? Which is the normal StreamController API plus addSync, addErrorSync and closeSync, which allows adding events synchronously (after listen has returned, not paused, and if there are no prior events still enqueued).

I'm working on these tests now and will add them later in a separate PR.

BTW could you, please, help me to understand if the following test is correct or not?

main() {
  asyncStart(2);
  int counter = 1;
  var stream = Stream<int>.multi((controller) {
    for (;;counter++) {
      controller.add(counter);
      if (counter % 5 == 0) {
        controller.close();
        counter++;
        return;
      }
    }
  });
  int i = 1;
  stream.listen((v) {
    print(v);
    Expect.equals(v, i++);
  }, onDone: () {
    Expect.equals(6, i);
    asyncEnd();
  });
  int j = 6;
  stream.listen((v) {
  print(v);
    Expect.equals(v, j++);
  }, onDone: () {
    Expect.equals(11, j);
    asyncEnd();
  });
}

The test works for me but it's unclear for me why. The output is

unittest-suite-wait-for-done
1
6
2
7
3
8
4
9
5
10
unittest-suite-success

Seems that the controller syncronously sends data to the first listener and then to the second. Is this expected? If yes, what's the difference between add and addSync?

[eernstg]

Looks good, just a couple of comments.

[sgrekhov]

Updated. PTAL.

[eernstg]

help me to understand if the following test is correct or not?

That question would probably fit just fine as an issue on the SDK repository with the label type-question.

[lrhn]

BTW could you, please, help me to understand if the following test is correct or not?

It's not wrong. I wouldn't depend on the interleaving always being what it is.

The Stream.multi callbacks here are both synchronous, which means they run immediately to completion when listen is called.
It doesn't matter whether they use add or addSync because no event can be emitted until listen has returned, so all five events are enqueued and a microtask is scheduled to deliver the the next enqueued value.
Both do this, the first one enqueues 1..5+done events and the second 6..10+done, and two microtasks are scheduled.
Then those trigger, each emitting one event and scheduling another microtasks to emit the next event.

It's guaranteed that the streams will emit those events, because all events are computed synchronously.

The scheduling gives the interleaving you see. I would not guarantee any specific interleaving of separate event sources. We can guarantee that the next enqueued event will be delivered in a later microtask, but not precisely which later microtask.

So, working as intended.