https://kotlinlang.org logo
#kotest
Title
# kotest
e

Emil Kantis

05/31/2021, 9:03 AM
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

wasyl

05/31/2021, 9:07 AM
Can you try
./gradlew test -Dkotest.framework.sourceref.disable=true
?
e

Emil Kantis

05/31/2021, 9:09 AM
No change 😕
🤔 1
w

wasyl

05/31/2021, 9:13 AM
I suppose the project isn’t opensource?
e

Emil Kantis

05/31/2021, 9:17 AM
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

wasyl

05/31/2021, 9:23 AM
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

Emil Kantis

05/31/2021, 10:33 AM
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

sam

05/31/2021, 12:02 PM
Almost certainly sounds like classpath scanning. Any huge jars on the classpath ?
e

Emil Kantis

05/31/2021, 12:35 PM
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

sam

06/01/2021, 2:29 PM
Are you open to trying a snapshot version to help narrow this down ?
e

Emil Kantis

06/01/2021, 2:31 PM
sure 🙂
s

sam

06/01/2021, 5:39 PM
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

Emil Kantis

06/01/2021, 5:40 PM
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

sam

06/01/2021, 5:59 PM
Is this android ?
e

Emil Kantis

06/01/2021, 6:33 PM
No, regular jvm (targeting jdk15 usually, but downgraded to 11 this build)
s

sam

06/01/2021, 6:34 PM
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

Emil Kantis

06/01/2021, 6:37 PM
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

sam

06/01/2021, 7:37 PM
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

Emil Kantis

06/01/2021, 7:43 PM
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

sam

06/01/2021, 7:43 PM
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

Emil Kantis

06/02/2021, 1:05 PM
3 Views