I believe parallel test execution in Gradle behaves the following way: - Test Scan or File List provides 100 test suites (for example) - Max Parallel Tests is set to 10 (for example) - Gradle spins off 10 worker processes that each take 10 test suites, and report back when they are done.
Assuming the above is correct, there is an obvious limitation in this implementation, in that if the first worker has very long first test suite, even after the other 9 workers are done, the first worker is still dragging through its remaining 9 test suites.
Is that a fair assessment?
If so, has anyone looked into real-time scheduling, such that: - Test Scan or File List provides 100 test suites (for example) - Max Parallel Test is set to 10 (for example) - Gradle spins up 10 worker processes, each that work from the same master queue of test suites and create a process to handle that test suite. This would allow the occasional “slow” worker to not have to finish their slow test suite, plus all the remaining work while the other workers just hang out. This keeps workers from “biting off more than they can chew”