Are there plans for kotest to support nested javascript tests (mybe runTest allows this)? I hava a h...

# kotest

[benkuly]

Are there plans for kotest to support nested javascript tests (mybe runTest allows this)? I hava a huge library with 500 kotest-tests and wanted to enabled JS without loosing advantages of nested tests... (apart from all the work to refactor 500 nested tests to not nested tests).

[sam]

The JS frameworks don't support promises in parent tests. Therefore we can't map kotest test functions to them as kotest test functions are coroutine based.

[sam]

Same thing with Kotlins own tests which are single level by being method based.

[benkuly]

runTest seems to have promise on method level. Could that be used by kotest as a workaround? Otherwise as far as I understand, I need to make my test not nested and then I could just switch to kotlin.test, because I use kotest-framework mainly because of nested tests^^

[sam]

runTest won't nest either

[benkuly]

I want to understand the problem: Why is it a problem to use e. g. runBlocking and spawn the needed coroutines?

[sam]

how do you model

test("foo") { 
  test("bar") {
     test("baz") { 
    }
  }
}

Where each block is it's own coroutine, and the underlying JS frameworks only support promises at the outer most layer

[benkuly]

So the parent support Promise?

[sam]

Not in JS no

[sam]

In kotest yes

[benkuly]

So as fas as i understood, mocha does support Promises in the it block. So maybe just something like this? This could be totaly wrong, but I want to understand, why this is not possible.

it("TestBlock"){
   runTest {
      
   }
}

[sam]

as I've explained, you can't map multiple levels to that single it block

[sam]

You have nested tests you said, so you can map your leaf parts to the it but the parent parts must map to the describe bit, and describe != promises in JS land

[sam]

context("foo") {
  test("bar") {
  }
}

Both of those are async in Kotest ^^

describe("foo") { <--- sync
  it("bar") { <--- promise
  }
}

In JS Land ^^

[sam]

so it doesn't map

[benkuly]

okay, and why not just work on the it level and run multiple tests within the it block? I know this would prevent running all tests, when on of them fails, but it would allow nested tests

context("foo") {
   test("bar") {}
   test("baz") {}
}

to

it("foo") {
   test("bar") {}
   test("baz") {}
}

[sam]

Two issues with that - 1) you wouldn't see nested tests in the output, so Kotest would just need to collapse all the tests into one and 2) someone is gonna have to update the test framework to do that.

[sam]

You could take your root level tests and run them all inside a single "it" block, so to the JS frameworks it looks like it's really just a single giant test, you wouldn't get anything nice in the output, other than the parent test name. If you're happy with that, and want to make the necessary changes to the test runners, I would review it.

[benkuly]

1. I could live with that constraint. Maybe the kotests JUnit XML Format Reporter could give a better output then?
2. If you think this is realistic, I could try that, because otherwise I would need to refactor 500 tests 😄

[sam]

Another simpler alternative would be a flag that simply ignores nested tests on JS, which would mean you could run your suite against native/jvm as normal, and for JS it's ignored until / if you migrated to non-nested tests.

[benkuly]

Sadly it's not that easy, bacause I don't have any experience with the kotest code-base and test frameworks at all ☹️ But here is an idea: https://github.com/kotest/kotest/pull/2957

[benkuly]

It seems to work, but I'm not sure if this is the right way.

[sam]

Seems a small change? That is sufficient ?

[benkuly]

It runs the tests without problems. I have two issues with this solution:
• beforeSpec and afterSpec seems to get ignored.
• The fail output doesn't make clear, which subtest has failed.
Maybe you have ideas to fix these issues, because I just don't understand, where to start 😄

[sam]

I think the second is because of what I was saying about everything being flattenee

[benkuly]

Doesn't kotest know, where the test failed and make a proper fail reason?

[sam]

Yes but you've changed the way it works in the pr right

[benkuly]

Yeah, It's just a proposal, because I've no experience with kotests internal code.