https://kotlinlang.org logo
Join Slack
Powered by
<https://x.com/bnormcodes/status/17556480333692888...
# kotest
j
e
How does this relate to Kotest? Built-in assertions by JetBrains? Something we should migrate our assertions to use?
j
m
Is it this, but backed by jetbrains? https://github.com/bnorm/kotlin-power-assert
👌 1
k
power assert looks very interesting, filed feature request https://github.com/kotest/kotest/issues/4044 🙂 also there is a talk from kotlinconf: https://www.youtube.com/live/G8pS1FzZlhk?si=Wt-QlGxxIuX83ZOh&amp;t=17600
o
I have this on my near-term Radar and had a chat with Brian at KotlinConf. I'd like to explore how best to integrate this. https://kotlinlang.slack.com/archives/CSYLDDZUY/p1715357985678589
c
(small note, but please remove the 
si=
parameter from YouTube URLs, it's used by YT to track who you share your links with and thus track which other people you know)
👍 1
Also, there is a channel for it now: #power-assert
From what I understand, Kotest needs to provide:
Copy code
fun <T> T.shouldBe(value: T, message: () -> String) {
    withClue(message) {
        this@shouldBe shouldBe value
    }
}
then, users need to add 
shouldBe
to the list of instrumented functions, and in theory, that's all that's necessary, and all existing code calling the existing 
shouldBe
 should be intrusmented. However, I don't have the time to actually try it and see what happens.
j
What is that 
withClue
? It is not mentioned in the docs
c
o
Let's see. I need to play around with it to figure out what might work. But always appreciating ideas from others.
j
Ah okay I was thinking it was a power assert thing
c
^ the same should probably be provided for 
shouldNotBe
as well
e
@CLOVIS wouldn't that break all infix functions? 😕
Or should the infix version just bridge to the message-supporting one?
c
How would it break them? You do not need to modify existing code (neither in Kotest nor in user projects), you just have to provide this one additionally.
(it needs to be in the exact same package as the real 
shouldBe
)
o
Do all matchers which would benefit from power-assert (mostly Core Matchers it seems) refer to shouldBe?
j
I doubt
power assert replaces each call, so it cannot dive in already compiled code
c
I don't think there's any necessity for this. If a user writes
Copy code
foo shouldContain "2"
they already get nice error messages thanks to Kotest matchers, so there is little benefit to using power-assert. However, users who write
Copy code
("2" in foo) shouldBe true
would benefit from power-assert. So I think only 
shouldBe
/`shouldNotBe` are necessary.
o
What if it's 
foo.bar[4].baz shouldContain "2"
?
c
Yeah, if you want to support that use-case, you have to create the same overload I showed for all matchers.
but the user could also write
Copy code
check("2" in foo.bar[4].baz)
and get the same error message, without any new code in Kotest, so…
o
Yep, that's always a possibility. Let's see if we can find a way to combine the readability of Kotest's matchers with power-assert deconstruction where it is useful.
➕ 2
k
> (small note, but please remove the 
si=
parameter from YouTube URLs, it's used by YT to track who you share your links with and thus track which other people you know) @CLOVIS, I wonder if there's a browser extension you could use to help clean up clicked urls? I can it'd be more effectively to automatically clean up urls on your end vs other people having to do so manually. If there's an extension like this, I would love to use it!
c
There probably is one, but even then, it would only protect the people who have it. It's more efficient to mention it publicly, so more people know about it.
s
3 Views
Open in Slack
PreviousNext
Powered by