You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Do we keep the waitUpTo(Duration) API as an "override" of the specified timeout?
Or do we remove it in favor of await() where the timeout is always specified with a separate clause? (I vote yes)
If we keep waitUpTo, do we rename it awaitUpTo to be consistent? (I vote yes, if we keep the API)
One neat consequence of this addition is that individual events in a MultiEvent or SequentialEvent can have different timeouts. Whichever times out first will throw a timeout exception, which is fine. Consider waiting for a spinner to come and go:
If the spinner doesn't first appear after 10 seconds, we'll get a timeout there. This is useful. Events are associated with their own timeouts, which makes sense. You can be waiting for multiple events, and each event might have vastly different expectations about how long they are allowed to take.
I guess in a MultiEvent it doesn't make that much sense because you're always returning the result of the first event that occurs, however you need only specify a timeout for one of the events, and that will suffice, functionally (however technically only one of the inner events will ever timeout which is a little odd).
The text was updated successfully, but these errors were encountered:
ie...
However this begs some questions:
waitUpTo(Duration)
API as an "override" of the specified timeout?await()
where the timeout is always specified with a separate clause? (I vote yes)waitUpTo
, do we rename itawaitUpTo
to be consistent? (I vote yes, if we keep the API)One neat consequence of this addition is that individual events in a MultiEvent or SequentialEvent can have different timeouts. Whichever times out first will throw a timeout exception, which is fine. Consider waiting for a spinner to come and go:
If the spinner doesn't first appear after 10 seconds, we'll get a timeout there. This is useful. Events are associated with their own timeouts, which makes sense. You can be waiting for multiple events, and each event might have vastly different expectations about how long they are allowed to take.
I guess in a MultiEvent it doesn't make that much sense because you're always returning the result of the first event that occurs, however you need only specify a timeout for one of the events, and that will suffice, functionally (however technically only one of the inner events will ever timeout which is a little odd).
The text was updated successfully, but these errors were encountered: