Hey, I've added a very small but convenient extension to provide scope in an assertSoftly block

inline fun <T, R> T.assertSoftly(assertions: T.() -> R): R {
   return io.kotest.assertions.assertSoftly { this.assertions() }
}

Are there any thoughts or objections about adding this to kotest, along with other similar scoping functions? An example of its use:

val user = buildUser()
user.assertSoftly {
    name shouldBe "Bob"
    role shouldBe Role.ADMIN
}

I thought we had that already tbh

No no no

Thanks for the quick reply! I'm curious what problems that code could cause

I think it messed up with other kind of tests, kind of overriding the context

Wow this is super interesting! Thank you so much for looking into this. Since I'm using this in my code right now I can't wait to hear what caused your reversal.

https://github.com/kotest/kotest/commit/b07e406b30bd2d7f3517816616fb4fe2980df2de This was the reversal commit

I'm going to play with this later! I'm curious!!

@LeoColman That issue was discussed here https://kotlinlang.slack.com/archives/CSYLDDZUY/p1594489972146700

You have a good memory @LeoColman! What is the tl;dr on the issue ?

I think the gist of it is that having the second case would always pass

Spec

as

this

if you want to use the other case

So if I read that correctly, it was an overloading issue. Thanks for the info! You probably saved me some future headaches here. Any thoughts on using a unique name for the receiver object version? assertSoftlyRun, or similar?

Apply is the kotlin stblib name for it

I only mentioned run because of the return value. Apply returns the context object itself which shouldn't really matter in this use case that I can think of

That's fair

And certainly apply makes more grammatical sense

applySoftly

sounds cute

"Apply softly" are instructions for lotion

what about the original name, and just

assertSoftly(object) { }

I mean, it's what we have today hahahah