WDYT about allowing top-level specs? i.e. just def...

# kotest-contributors

[Emil Kantis]

WDYT about allowing top-level specs? i.e. just defining a spec like

// any test source file

stringSpec("My spec") {
  "my test" {
     foo shouldBe bar
  }  
}

[Emil Kantis]

Kotlin will generate a wrapping class based on the filename, so if the example was defined in foo.kt, we would get a FooKt class calling the stringSpec function

[Emil Kantis]

Although.. it would fuck all navigation stuff.. so probably a terrible idea 💩

[Alex Kuznetsov]

and the advantages of this are?

[Emil Kantis]

reduced ceremony mainly, but we probably need a named symbol for users to navigate to with fuzzy find etc

[Alex Kuznetsov]

that would not be very high on my list of priorities

[LeoColman]

I think we actually have this

[LeoColman]

Or at least we used to have it at some point. Let me dive history a bit

[LeoColman]

https://github.com/kotest/kotest/pull/1144

[LeoColman]

This points me that the final solution became the test factories, but I believe a top level test factory can be executed

[LeoColman]

It was something like that. @sam really liked it and implemented something for this

[LeoColman]

Wait, actually

Most notable change is that test factories (previously value specs) are not in themselves considered executable units.

Buried by my own words xD

[LeoColman]

How I can remember this and not remember if I had lunch or not is beyond me.

[Emil Kantis]

Maybe your head is too busy memorizing 4000 kotest PRs/issues 😁

[Emil Kantis]

impressive, lol

[sam]

We allowed tests in kotlin scripts in the past as a hidden feature I was working on