Thank you. So I'll add the request(1) before the expectComplete(). I
actually use the .runWih(TesSink.probe) in my test, I used the
TestSubscriber.manualProbe just in the demonstration example to be able to
print the intermediate results.
Jakub
On 19 February 2018 at 12:18, Patrik Nordwall
btw, probably easier to use .runWith(TestSink.probe) in that example, or
.runWith(Sink.seq).futureValue
On Mon, Feb 19, 2018 at 12:12 PM, Patrik Nordwall wrote:
> Doc improvement is welcome. If you add request(1) before the
> expectComplete it’s not undefined, then
Doc improvement is welcome. If you add request(1) before the expectComplete
it’s not undefined, then you are supposed to get it.
/Patrik
mån 19 feb. 2018 kl. 07:40 skrev Jakub Kahovec :
> I had another thought about this behaviour and two things came to my mind.
> First,
I had another thought about this behaviour and two things came to my mind.
First, it might be worth mentioning this somewhere in the documentation
about testing as other users might also experience this and I think didn't
see this mentioned anywhere in the docs. And second, is it safe to use
I see. Thank you Patrik for the explanation.
Jakub
On Friday, February 16, 2018 at 9:55:45 PM UTC+1, Patrik Nordwall wrote:
>
> It is allowed to ”delay” delivery of the complete signal when there is no
> demand. This behavior is undefined, i.e. some stages deliver it
> immediately, some only
It is allowed to ”delay” delivery of the complete signal when there is no
demand. This behavior is undefined, i.e. some stages deliver it
immediately, some only when demand is requested. This is as expected and in
such test you have to request enough to be sure to get the completed signal.