-
Notifications
You must be signed in to change notification settings - Fork 623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test discovery: Make classpath scanning fallback configurable #4017
base: master
Are you sure you want to change the base?
Conversation
If it sends all but one a non empty list, how does the maxParallelForks do anything? Does it just spawn multiple kotest's that don't do anything? |
It spawns multiple Kotests (each in its own JVM). Then almost all of them get a non-empty list of classes, so these Kotest's do their stuff. Just (the last?) one gets an empty list and (with this PR) does nothing (instead of doing a classpath scan and running all tests again). Seems like a classical "off by one" error in Gradle's Java test task. More detailed description here: #3973 (comment) Considerations here: #3973 (comment) #3973 shows how the drama unfolds. |
Should we consider moving to making classpath scanning disabled unless the |
Following up on #3973 (comment): Given its history and current usage, I see two viable options regarding JUnit 5 discovery in Kotest:
|
Fixes #3973.
Introduces a system property
"kotest.framework.discovery.classpath.scanning.enabled",
defaulting to "true".
This exists to work around a Gradle bug which occurs with JunitPlatform
and
maxParallelForks > 1
(process parallelization). In this case,depending on the number of CPU cores, Gradle may invoke all but one
Kotest launchers with a non-empty list of class selectors, and the
remaining Kotest launcher with an empty list of class selectors,
triggering a classpath scan in Kotest. In that case, tests will execute
twice (discovered once via a class selector, a second time via the
classpath scan).
Also makes Kotest-internal debug logging multi-process-aware,
naming log files like "kotest-PID.log", containing the respective
process id.