-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
Switch to assertFailsWith #8177
Conversation
fail<Any>("Second connection should be refused") | ||
} catch (e: ConnectException) { | ||
assertThat(e.message!!).contains("refused") | ||
}.also { expected -> |
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.
This idiom isn’t perfect, but it was easy enough to Structurally Replace and it makes the diffs pretty easy to review
} catch (e: ConnectException) { | ||
assertThat(e.message!!).contains("refused") | ||
}.also { expected -> | ||
assertThat(expected.message!!).contains("refused") |
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.
I also renamed e
to expected
wherever I could
@@ -21,6 +21,7 @@ import assertk.assertions.hasMessage | |||
import assertk.assertions.isEmpty | |||
import assertk.assertions.isEqualTo | |||
import java.io.IOException | |||
import kotlin.test.assertFailsWith |
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.
I’m using assertFailsWith instead of assertFailure because assertFailure needs a 2nd assertion to specify the exception type
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.
Yeah I argued for an overload that took a reified exception type when I added assertFailure
and lost (or, well, didn't press it too hard when given push-back).
Maybe file a feature request and we can try again?
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.
testImplementation(libs.kotlin.test.annotations) | ||
testImplementation(libs.kotlin.test.common) | ||
testImplementation(libs.kotlin.test.junit) |
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.
The need for all three of these is very strange. You should really only need "common" as the Gradle module metadata will resolve both the annotations and the junit implementation automatically in almost all cases.
There are a few exceptions, maybe in the MWS modules, where you have to be explicit. But 99% of modules should get the automatic behavior.
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.
Yeah, I’m frustrated with this one. For reasons unclear to me omitting libs.kotlin.test.junit
causes compile to fail.
> Task :okhttp-brotli:compileTestKotlin FAILED
e: file:///Volumes/Development/okhttp/okhttp-brotli/src/test/java/okhttp3/brotli/BrotliInterceptorTest.kt:24:20 Unresolved reference: assertFailsWith
Saw some out-of-order imports. Probably need a |
The whole repo needs some Spotless love. It’s currently misconfigured and broken. I’ve got that on my queue for demultiplatform cleanup. |
No description provided.