Open stefnoten-aca opened 1 year ago
@stefnoten-aca Thanks for finding that!
Unfortunately, no promises of a fix 😔. The issue is related to the StepVerifier design and what you observe could be a design flaw.
The problem is that expectNoEven
triggers VirtualTimeScheduler
to progress by 1 second. Since the startWith
has nothing to do with schedulers, the progress will basically do nothing, hence no events will be produced during the expectNoEvents
stage. Unfortunately, we don't have a mechanism to put the expectNoEvents
stage back in the queue and wait for another event and check whether the event arrived during expectation or not.
All that said - try to redesign your test and use a different approach to verify event time.
One possible workaround could be the use of elapsed
operator in combination with predictable virtual time
@Test
void shouldFailButDoesNot() {
StepVerifier.withVirtualTime(() -> Flux.never().startWith("a").elapsed())
.expectSubscription()
.expectNoEvent(Duration.ofSeconds(1)) // should fail
.expectNextMatches(e -> e.getT2().equals("a") && e.getT1() >= 1000)
.verifyTimeout(Duration.ofSeconds(1));
}
Expected Behavior
expectNoEvent
fails when a emission happensActual Behavior
expectNoEvent
does not fail on an emissionSteps to Reproduce
Also incorrectly succeeds:
StepVerifier.create
instead ofwithVirtualTime
thenCancel().verify()
instead ofverifyTimeout
(apparently a known case since #1440)Your Environment
java -version
): Temurin-17.0.4+8uname -a
): Darwin Kernel Version 21.6.0