-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow specifying the timeout for runTest
#3603
Conversation
Deprecate `dispatchTimeoutMs`, as this is a confusing implementation detail that made it to the final API. We use the fact that the `runTest(Duration)` overload was never published, so we can reuse it to have the `Duration` mean the whole-test timeout in a backward-compatible manner.
Regarding the two changes (timeout + experimentality markers) for the price of one: I'll split the PR in two if it makes it easier to review this. |
Please squash commits into two prior to merge and mention the corresponding |
5bca4b5
to
9fd86bb
Compare
) | ||
): TestResult { | ||
if (context[RunningInRunTest] != null) | ||
throw IllegalStateException("Calls to `runTest` can't be nested. Please read the docs on `TestResult` for details.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity: is it better/more readable than check(context[RunningInRunTest] != null)) { ..message.. }
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. I think I wrote it this way to be able to place a breakpoint on throw
, but one can do it with check
also:
check(...) {
"message" // breakpoint here
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory, yes, I just struggle to make it work sometimes. Line breakpoints are much more reliable.
var timeoutError: Throwable? = null | ||
var cancellationException: CancellationException? = null | ||
try { | ||
withTimeout(timeout) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is withTimeout
guaranteed to only throw after the invokeOnCompletion
handler has finished its work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, all intermediate handlers are invoked synchronously, thus making it impossible for coroutine to finalize its state (-> throw or return to the caller)
9da1fcf
to
4fe30ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job!
Deprecate
dispatchTimeoutMs
, as this is a confusing implementation detail that made it to the final API.We use the fact that the
runTest(Duration)
overload was never published, so we can reuse it to have theDuration
mean the whole-test timeout in a backward-compatible manner.Fixes #3270