Skip to content
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

Merged
merged 11 commits into from Feb 21, 2023
Merged

Conversation

dkhalanskyjb
Copy link
Collaborator

@dkhalanskyjb dkhalanskyjb commented Jan 27, 2023

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.

Fixes #3270

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.
@dkhalanskyjb dkhalanskyjb marked this pull request as ready for review February 1, 2023 14:37
@dkhalanskyjb
Copy link
Collaborator Author

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.

@qwwdfsad
Copy link
Member

qwwdfsad commented Feb 6, 2023

two changes (timeout + experimentality markers) for the price of one

Please squash commits into two prior to merge and mention the corresponding Fixes #foo in the message

)
): TestResult {
if (context[RunningInRunTest] != null)
throw IllegalStateException("Calls to `runTest` can't be nested. Please read the docs on `TestResult` for details.")
Copy link
Member

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.. }?

Copy link
Collaborator Author

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
}

Copy link
Member

@qwwdfsad qwwdfsad Feb 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(for the future) IDEA allows you to place a breakpoint into a specific part of such expressions:
image

Copy link
Collaborator Author

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.

kotlinx-coroutines-test/common/src/TestBuilders.kt Outdated Show resolved Hide resolved
kotlinx-coroutines-test/common/src/TestBuilders.kt Outdated Show resolved Hide resolved
var timeoutError: Throwable? = null
var cancellationException: CancellationException? = null
try {
withTimeout(timeout) {
Copy link
Collaborator Author

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?

Copy link
Member

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)

Copy link
Member

@qwwdfsad qwwdfsad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants