Kotlin: Support `assertThat(foo) { isNotNull() isNotEqualTo(bar) ... }`

[cpovirk]

It's already possible to write nearly that by using apply:

assertThat(foo).apply {
  isNotNull()
  isNotEqualTo(bar)
}

Might it be worth a shortcut? Anecdotes welcome.

[cpovirk]

I'm reliably informed that the implementation would be something like:

operator fun <T: Subject> T.invoke(assertions: T.() -> Unit): Unit = this.assertions()

[JakeWharton]

Yep, that'll work!

I also flip the parameter to a receiver, but that requires one extension per subject type instead of the invoke trick.

[vRallev]

@JakeWharton Is this what you mean?

fun assertThat(string: String, assertions: StringSubject.() -> Unit) {
  assertThat(string).run { assertions() }
}

This would allow

assertThat("hello") {
  isNotEmpty()
  isEqualTo("hello")
}

[JakeWharton]

No. The parameter becomes a receiver of the extension.

fun String.assertThat(assertions: StringSubject.() -> Unit) = assertThat(this).assertions()

[vRallev]

Got it. Then it reads differently, though. But that's a matter of taste I guess.

[netdpb]

@JakeWharton Would it then read as follows? Does that look better or worse than the explicit assertThat("hello") call?

"hello".assertThat {
  isNotEmpty()
  isEqualTo("hello")
}

[JakeWharton]

Well the input is rarely so trivial.

getApi()
  .makeSomeCall()
  .performSomeAction()
  .assertThat {
    isNotEmpty()
    isEqualTo("hello")
  }

[cpovirk]

For ease of searching: I'm told that, in addition to apply, it's also possible to use let or with.

https://kotlinlang.org/docs/reference/scope-functions.html#apply
https://kotlinlang.org/docs/reference/scope-functions.html#let
https://kotlinlang.org/docs/reference/scope-functions.html#with

Of those existing options, it seems like apply is most sensible here [edit: eh, I'm not sure why I thought that, and the docs on scope functions suggest probably with or let as I read them now? But I do like that apply returns the Subject, as discussed below....], though there may be subtleties that I'm unaware of.

For purposes of this issue, though, the real choice is the one being discussed above between string.assertThat and assertThat(string).

[netdpb]

@JakeWharton sure. So I guess the question is which of these seems better, and why?

getApi().makeSomeCall().performSomeAction().assertThat {
  isNotEmpty()
  isEqualTo("hello")
}

or

assertThat(getApi().makeSomeCall().performSomeAction()) {
  isNotEmpty()
  isEqualTo("hello")
}

The latter establishes the context of assertion right at the start, but the former maybe allows you to attach the assertion more directly to the clause that names the value ("some action").

Which is more discoverable, harder to get wrong? Which seems more Kotlin-idiomatic?

[netdpb]

@cpovirk If you're talking about using a scope function on the result of calling assertThat(foo), then I think it has to be run, with, or apply. let and also would force you to refer to the subject as it, which I think is worse:

assertThat(foo).let {
  it.isNotEmpty()
  it.isEqualTo("foo")
}

apply would return the Subject itself, which may enable things we don't want to see, like

assertThat(foo).apply {
  isNotEmpty()
  isEqualTo("foo")
}.contains("f")

run and with return whatever the last expression statement in the block returns, which for most assertions is Unit/void, which seems more like what we want (the assertion is the whole statement).

Finally, the difference between run and with is the same as the difference we're talking about between assertThat(foo) { assertions } and foo.assertThat { assertions } (with is the former style and run the latter).

@JakeWharton please check me as I'm learning this stuff: did I get that right?

[cpovirk]

Interesting, thanks.

It sounds like run (and with) could enable the same kind of weirdness as apply, arguably only worse:

assertThat(foo).run {
  doesNotContain("foo")
  containsAtLeast("bar", "baz")
}.inOrder()

But maybe that's so weird that no one would do it :)

Probably the takeaway is that Unit is the best return type for writing our own API. And sure enough, that's the return type we've been using in our proposals :)

(The other takeaway might be that, although users have options already, it's not necessarily obvious which is best, especially given the (remote) possibility of weird usages. That might make this feature slightly more useful than I'd initially realized.)

[cpovirk]

I am interested in thoughts from Jake (and other Kotlin users) on what is most idiomatic, but I also want to highlight his point from earlier:

The string.assertThat approach "requires one extension per subject." That's not a problem for core Truth and even ProtoTruth, etc., since we can just add all those extension methods. It's also arguably not a problem for pure-Kotlin Truth Subject classes, since we can recommend that their authors define an extension method, at least once we write Kotlin instructions for Subject authors. But it feels a little unfortunate that most pure-Java custom Subject classes won't come with such extension methods. Of course users can always define their own, but it's a minor obstacle for users to confront -- especially because foo.assertThat will initially appear to "work"... but by returning a plain Subject instead of the expected FooSubject. (I guess this is really just the same problem that users always see when they need to import a new Subject.assertThat method, though?)

I don't think this rules out the foo.assertThat approach -- though I admit that I'm already slightly biased against it because users will already have to understand assertThat(foo), and I'm not sure foo.assertThat is "better enough" to justify 2 styles and the resulting debates over which is better for a given usage. But I don't feel that strongly, especially if foo.assertThat would be more idiomatic.