How does Kotest manage to declare tests on Kotlin/Native? I don't really understand how the codebase...

# kotest

[CLOVIS]

How does Kotest manage to declare tests on Kotlin/Native? I don't really understand how the codebase is structured

[sam]

I don't understand the question, can you ask it in a different way

[CLOVIS]

To my knowledge, the only way supported by the Kotlin team to declare tests on Native is through the @Test annotation. Since Kotest is able to declare tests in loops/conditions, then it can't be doing it like that. So how does it work?

[sam]

Ah I see. Basically uses a compiler plugin, like how kotlin team do it

[sam]

instead of looking for @test, it looks for kotest specs

[CLOVIS]

How difficult are these types of compiler plugins to write?

[CLOVIS]

I really want to be able to declare top-level test functions like this:

@Test
fun StringSpecScope.myTestSuite() {
    ...
}

[CLOVIS]

Using JUnit5, it's not hard. I don't know how to declare that top-level function as a test entry point on JS or Native.

[Oliver.O]

I'd say this goes against the grain of the whole Kotest architecture. Specs are discovered (on Js and Native: via a compiler plugin). Then each spec's "body" is executed, with test functions registering their test lambdas. To use the above extension function with a spec, you'd have to sort of wrap it into a lambda and register that within the spec's "body".

[CLOVIS]

Yes? How does that change anything, other than “less boilerplate”?

[Oliver.O]

What do you mean by "less boilerplate"? And given the static declaration above, which individual spec (an object!) would you register it with?

[sam]

I did once play about with putting tests inside kotlin scripts - .kts files. And it worked. You could do

val mytest = funSpec {
  // test here
}

And it worked. Each test being a value. But until jetbrains make compiler plugins and kotlin scripts stable, things are changing too rapidly to build on this for a public release.