set the channel description: Discussions of using the github.com/google/truth testing framework in kotlin.

Hi, we recently started using Truth at Dropbox and are wondering what's the best way to expect exceptions. We're looking for a simple to use API similar to Kotlin's

assertFailsWith

val exception = assertFailsWith<DroidLoggerConfigurationException> {
            createDroidLoggerConfiguration(ip, port)
        }
    assertThat("IPV4 address $ip is not valid").isEqualTo(exception.message)

I've seen this snippet being included in many GH repos https://github.com/JakeWharton/SdkSearch/blob/17c25e0b297ec2f7047803fd92888fa8b92ba7b5/backend/dac-proxy/src/test/java/com/jakewharton/sdksearch/proxy/truth.kt#L6 Can that be added to Truth itself?

You'd have to ask the google team, as they are looking at accepting more kotliny things. But inside Google, they just use (for non kotlin stuff) assertThrows() from junit 4.13, and in Square we use kotlin.test's assertFailsWith<>. There's no terribly important reason it needs to be in truth. It's pretty trivial to add in a local testing library.

There are some ongoing github issues talking about different kotlin things, notably https://github.com/google/truth/issues/536. I think your suggestion might be a reasonable one to propose.

Thanks for the response. For now, we'll also use

kotlin.test.asssertFailsWith<>

. We have a custom linter that dissuades developers from using non-Truth assertions, but we'll whitelist

assertFailsWith

specifically.

There's no terribly important reason it needs to be in truth.

I agree, but it's important for consistency and reduce confusion for devs on which APIs to use. I filed: https://github.com/google/truth/issues/621

Cool. I'll put serious odds on it being rejected, as "in truth for completeness" was an argument to include a variant of the JUnit one before, and it was rejected (because it's basically duplication, and people have junit already in their deps in nearly all cases). But might be useful in a kotlin-specific set of extensions, if it would require adding kotlin.test for no other reason.

I put in my 2c.