https://kotlinlang.org logo
Join SlackCommunities
Powered by
Wrote a short post on configuring Kotest for faste...
# kotest-contributors
e
Wrote a short post on configuring Kotest for faster test startup. Would anyone like to review it?
Post here. https://kantis.github.io/posts/Faster-Kotest-startup/ Pictures are broken, will fix soon
a
Looks good! The section "Using a Kotest config without scanning" might benefit from a sentence or two about what a "Kotest config" is for folks who don't know. It's also not clear if you use that config property in addition to or instead of the other recommendations.
thank you frog 1
As an aside, the post makes the assumption that no one reading the post uses any of those features. If they're rarely used, maybe we could consider disabling scanning by default, and making it opt-in for the few folks who need it so that most users will have a faster startup time?
One last bit of feedback: at the end of the intro where you mention "Kotest uses ClassGraph to scan for Specs, Kotest configuration, @AutoScan annotations, etc.", you might consider linking to the docs for those features so that readers can tell whether or not they're using them, so they know if they can safely apply your suggestions.
👍 1
e
Good point. Might try to explain each setting very briefly even.
And regarding changing the defaults. I know we have discussed changing them for 6.0 (at least some of them)
o
Kotest uses ClassGraph to scan for Specs
Under normal circumstances, Kotest does not. Gradle (or Maven Surefire) passes a list of classes to Kotest.
e
Even when just running 
./gradlew check
, for instance?
o
Yes. You could verify this by setting 
KOTEST_DEBUG=true
and looking at the list of classes in the debug log under 
classSelectors=
.
e
How does it find them then? First a discovery request with class path scanning and then a test invocation?
o
No. Gradle scans on its own initiative without an idea what might constitute a test class. Then it dumps all classes (test or not) via JUnit Platform onto the test framework. https://github.com/kotest/kotest/issues/3973#issuecomment-2107882004
e
lol, brilliant
o
Absolutely!
And then shard the list of classes for (fork-style) parallelization:
So if the classpath contains 29 classes, of which only 3 (just 10%) are actual test specs, the chances of having the actual tests distributed correctly across multiple runners are slim.
e
Do you know in which scenarios we actually do discovery in? When running tests using the Kotest IJ plugin?
o
I'm letting the IJ plugin use Gradle for runs. I've not looked inside, so I really don't know.
e
👍
Big thanks for the feedback and corrections. Article has been updated. I'll post it in #kotest and link it from the blogs page later 🙂
👍 1
🎉 1
Open in Slack
PreviousNext
Powered by