https://kotlinlang.org logo
Join Slack
Powered by
What might be the reason that a test execution tak...
# kotest
e
What might be the reason that a test execution takes 1000x more time when executed using 
./gradlew test
compared to running the test through IntelliJ?
w
Can you try 
./gradlew test -Dkotest.framework.sourceref.disable=true
?
e
No change 😕
🤔 1
w
I suppose the project isn’t opensource?
e
Sadly not. I was thinking it might be related to classgraph scanning in gradle but there's not a whole lot of files/classes and increasing max mem made no difference
Specifying the exact test using 
--tests "<http://package.to|package.to>.test.SomeTest"
makes it run fast
w
If you don’t use 
@AutoScan
you can try 
kotest.framework.classpath.scanning.config.disable
and 
kotest.framework.classpath.scanning.autoscan.disable
properties which will disable some classpath scanning (but only that related to listeners and extensions, not the one for tests) *also will disable scanning for configuration classes
👀 1
Oh that’s right, I recently discovered that the other classpath scanning in the project, the one to discover tests, isn’t actually executed when running tests from Gradle, because JUnit engine will pass all classes names to Kotest, which will only filter for specs
e
None of the options made a difference 😞 probably need to attach some profiler to see wtf is going on but it's been ages since I did something like that
s
Almost certainly sounds like classpath scanning. Any huge jars on the classpath ?
e
Shouldn't be.. very few dependencies:
Copy code
dependencies {
    implementation("org.slf4j", "slf4j-api", "1.7.30")
    implementation("org.slf4j", "slf4j-log4j12", "1.7.30")
    testImplementation("io.mockk", "mockk", Versions.MOCKK)
    testImplementation("io.kotest", "kotest-runner-junit5-jvm", Versions.KOTEST)
}
s
Are you open to trying a snapshot version to help narrow this down ?
e
sure 🙂
s
If you use the latest snapshot 5.0.0.278-SNAPSHOT and enable KOTEST_DEBUG=true as an env var
then you should get loads of logging
if you do, then can you grab the lines starting with JUnit
e
Testing right away 🙂
👍🏻 1
Hmm, didn't get any output from setting 
KOTEST_DEBUG
😕 but running gradle with debug flag showed that it was stuck in a loop doing this: https://gist.github.com/Kantis/85e13c62a9795691b00eadfe91c91b3a
s
Is this android ?
e
No, regular jvm (targeting jdk15 usually, but downgraded to 11 this build)
s
Not sure what this Waiting to acquire shared lock on daemon addresses registry thing is but seems to be a load of them in google, in unrelated projects
e
Will search a bit and see if I can find any common factor,will update in a bit..
👍🏻 1
Okay, my impression is that the Waiting to acquire shared lock was a red herring, it's something that happens when daemon's health check is invoked..
s
ok
if you can set that KOTEST_DEBUG=true env var we can get more details
it can be set as a system property too
Copy code
test {
    systemProperty "KOTEST_DEBUG", "true"
}
might work
e
Okay, flag is set according to 
System.getenv
. Is this what we're looking for?
Copy code
2021-06-01T21:40:56.233+0200 [DEBUG] [TestEventLogger]     1622576456233 Registering junit dynamic test: : [engine:kotest]/[spec:some.package.SimulationTest]/[test:Simulation tests 1]/[test:Input should match]
2021-06-01T21:40:56.233+0200 [DEBUG] [TestEventLogger]     1622576456233 Notifying junit that execution has started: : [engine:kotest]/[spec:some.package.SimulationTest]/[test:Simulation tests 1]/[test:Input should match]
s
Should be stuff before that
but yes that kind of thing
look for
Copy code
JUnit discovery request
and
Copy code
JUnit discovery completed
👍 1
Just following up that we fixed it. Issue was in mock usage.
e
9 Views
Open in Slack
PreviousNext
Powered by