https://kotlinlang.org logo
Join Slack
Powered by
Is Kotest broken on JS? I can't figure out a way t...
# kotest
c
Is Kotest broken on JS? I can't figure out a way to execute JS tests. Even the demo doesn't seem to run the JS tests:
Copy code
$ ./gradlew jvmTest jsBrowserTest
> Task :jvmTest
io.kotest.examples.mpp.UUIDJvmTest[jvm] > uuids should be in be type 4 format[jvm] PASSED
io.kotest.examples.mpp.data.DataDrivenTest[jvm] > PythagTriple(a=3, b=4, c=5)[jvm] PASSED
io.kotest.examples.mpp.data.DataDrivenTest[jvm] > PythagTriple(a=6, b=8, c=10)[jvm] PASSED
io.kotest.examples.mpp.uuid.UUIDTestCommon[jvm] > uuids should be somewhat unique![jvm] PASSED
Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
👀 1
e
Don't have very much experience with these parts of Kotest.. it involves the Kotlin compiler plugin which JetBrains tend to do breaking changes to every now and then.. I'll see if I can figure anything out
I seem to find reports in 
build/reports/test/jsTest
and 
build/reports/test/jsBrowserTest
if I run the tasks.. So guessing something is wrong with console reporting
a
maybe change 
tasks.named<Test>("jvmTest") {
to 
tasks.withType<Test>().configureEach {
c
@Emil Kantis It's not just the console, if I execute them in IDEA they don't appear either.
a
IntelliJ requires stdout is enabled to be able to display the tests
when tests are triggered by IntelliJ, it injects a Gradle init script which adds some code that will add some XML to stdout that IntelliJ will parse and use to display the tests
e
I think it adds a Gradle TestListener to the test task? it shouldn't be dependent on stdout (was digging into this a few days ago, but might've misunderstood something ofc.)
a
I also might have misunderstood something
c
Strange. Well currently IDEA sees the JVM tests but doesn't see the JS tests. I'll have to try again to see if the test reports are generated, but anyway if the results don't appear in IDEA/Gradle output I can't use it.
a
Copy code
tasks.withType<Test>().configureEach {
   testLogging {
      showExceptions = true
      showStandardStreams = true
      events = setOf(
         org.gradle.api.tasks.testing.logging.TestLogEvent.FAILED,
         org.gradle.api.tasks.testing.logging.TestLogEvent.PASSED,
         org.gradle.api.tasks.testing.logging.TestLogEvent.STANDARD_OUT,
      )
      exceptionFormat = org.gradle.api.tasks.testing.logging.TestExceptionFormat.FULL
   }
}
does adding this change anything @CLOVIS?
c
Sorry, I can't test until tonight. I was just executing the unmodified 
master
branch of the demo, if you want to test yourself
@Adam S I tested your example, and it doesn't change anything.
It's a shame, Kotest seemed really promising, but if it can't run tests 😅
e
sounds like a bug we might need to fix 😜
r
There was a Kotlin bug in 1.4 which eventually was fixed in kotlin 1.6 as far as I remember which can cause this issue. The demo uses 1.5 (at a first glance) so could be affected by the bug
c
I tried to configure Kotest in a 1.7.20 project and had the same issue. I then tried the demo, and mentioned the demo here because it's much easier for the maintainers to reproduce and much less likely that I did something wrong (it's their code, after all!)
e
I'm starting to think Kotlin 1.6.21 JS test implementation is incompatible with Gradle 7.6.. 😛
Copy code
Caused by: java.lang.NoSuchMethodError: 'void org.gradle.api.internal.tasks.testing.TestResultProcessor.failure(java.lang.Object, java.lang.Throwable)'
  at org.jetbrains.kotlin.gradle.internal.testing.TCServiceMessagesClient.failure(TCServiceMessagesClient.kt:176)
  at org.jetbrains.kotlin.gradle.internal.testing.TCServiceMessagesClient.ensureNodesClosed(TCServiceMessagesClient.kt:530)
  at org.jetbrains.kotlin.gradle.internal.testing.TCServiceMessagesTestExecutor$execute$1.invoke(TCServiceMessagesTestExecutor.kt:81)
  at org.jetbrains.kotlin.gradle.internal.testing.TCServiceMessagesTestExecutor$execute$1.invoke(TCServiceMessagesTestExecutor.kt:46)
  at org.jetbrains.kotlin.gradle.internal.testing.TCServiceMessagesTestExecutionSpec.wrapExecute$kotlin_gradle_plugin(TCServiceMessagesTestExecutor.kt:28)
  at org.jetbrains.kotlin.gradle.internal.testing.TCServiceMessagesTestExecutor.execute(TCServiceMessagesTestExecutor.kt:46)
  at org.jetbrains.kotlin.gradle.internal.testing.TCServiceMessagesTestExecutor.execute(TCServiceMessagesTestExecutor.kt:34)
  at org.gradle.api.tasks.testing.AbstractTestTask.executeTests(AbstractTestTask.java:495)
  at org.jetbrains.kotlin.gradle.targets.js.testing.KotlinJsTest.executeTests(KotlinJsTest.kt:155)
Trying to bump Kotlin version to see if it helps
c
Do you know if there is a chance to get the fix in the next week or so? I'm using the same test battery to validate multiple implementations of the same interface, and doing that with kotlin.test is really not great (I'm having to hack things with test case inheritance… not fun). I'm very interested by Kotest's ability to declare tests dynamically
e
I think I can try to track down the issue at least. You might be forced to downgrade to an older version of gradle and sticking with Kotlin 1.6.21 or so for now. Seems like they changed some things with how JS tests work in 1.7 and I don’t know how big of a deal that is to fix.
c
Downgrading is not an option for me, I depend on Compose. Is there a reason Kotest is so late behind Kotlin?
e
Kotest tend to stick behind to not force users to upgrade. Normally it isn’t an issue but compiler plugins API which is used for multiplatform testing has had breaking changes quite often
I think the current plan is that Kotest 5.6 will target a newer Kotlin version
c
I prefer a lib that forces me to upgrade than one which forces me to downgrade...
If you create a GH issue or some other kind of tracking for this, can you send it here so I can subscribe to it?
e
46 Views
Open in Slack
PreviousNext
Powered by