Is it worth considering making `should(matcher: (T...

# kotest

[phldavies]

Is it worth considering making should(matcher: (T) -> Unit) inline as part of 6.x? Possible the same for shouldNotBeNull

[phldavies]

As a side note, was there a reason for should and shouldBeTypeOf taking (T) -> Unit and shouldNotBeNull taking T.() -> Unit?

[Alex Kuznetsov]

can you elaborate how it'll make your life easier?

[Klitos Kyriacou]

I don't understand why Kotest duplicates the features of Kotlin's stdlib in many ways. This is another example. This usage of should(matcher: (T) -> Unit) doesn't seem to bring any added benefit over Kotlin scope functions. The latter are indeed inline. So if you really need should to be inline, just replace it with `with`:

Instead of: someString should { it shouldStartWith "abc"; it shouldNotContain "xyz" }
Do this: someString.let { it shouldStartWith "abc"; it shouldNotContain "xyz" }
Or: with(someString) { this shouldStartWith "abc"; this shouldNotContain "xyz" }

[phldavies]

the main reason for should being made inline is to support suspend in the block.

i.e. httpResponse should { it.bodyAsText() shouldContain "abc" }

Indeed we have been using .also instead of should in some places due to this, however the purpose of the should method is to provide the better semantics when writing tests.

[sam]

"should" is historic, and you could use scope functions. I don't think I've used should in 5 years, I just chain shouldBe together

[sam]

someString.shouldStartWith("abc").shouldNotContain("xyz")

[sam]

that's also useful for the matchers that use contracts, eg

somePossibleNullString.shouldNotBeNull().shouldContain("foo")

[phldavies]

we tend to use should for grouping several property assertions:

myResult should {
  it.id.shouldNotBeEmpty()
  it.age shouldBeLessThan 12
}

etc

[phldavies]

it's also useful for when the shouldBlah function returns Unit (i.e. shouldHaveStatus in the ktor assertions)

[sam]

Yeah fair, actually for 6 we should change them all to not return unit if we can

[Alex Kuznetsov]

I'd vote for releasing 6 first. It has lots of improvement in limbo since 2024. then we can continue with other improvements

[sam]

Once 6 is out we can't make breaking changes anymore

[sam]

But I'm general I agre

[sam]

I think 6 is ready just about. Will do m5 today and rc this week.

[Alex Kuznetsov]

from where I sit, better matching of texts and collections should be more widely used that changes in should

[phldavies]

It's also fairly nice to be able to uses shouldNotBeNull

myResult shouldNotBeNull {
  id.shouldNotBeEmpty()
  age shouldBeLessThan 12
}

which is a handy way of writing your own "shouldBeValidResponse()` style helpers

Either way, marking the two historic functions (assuming shouldNotBeNull taking a block is historic too) as inline should be of very little impact but allows for the use of suspend calls inside.

[sam]

yes happy to swap them to inline, do you want to make a PR ?

[phldavies]

PR is already up

[sam]

oh yeah nice, approved

[sam]

windows failed, looks unrelated, I'll kick it off again