You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Small projects probably won't notice the slight increase in overhead with testForkGrouping enabled, while larger projects would benefit substantially from the parallelism. And people can turn it off if necessary.
Mill's been using it since 0.12.0 and it's been pretty robust, probably can make it the default in 0.13.0
The text was updated successfully, but these errors were encountered:
In my larger projects, testForkGrouping increased test time significantly. This is most likely project and hardware specific but I have yet to find the project where this setting results in relevant faster tests on my hardware.
I think it depends on how big your test suite classes are and how long they take to run. If your classes are numerous and fast, then the overhead of spawning JVMs for each one dominates. If they are few and slow, then the overhead is small and the parallelization benefits win out
It looks to me this should be a runtime setting rather than build script defined, since it may vary for user / machine / use-case and also ideally should not affect any built outcome.
Small projects probably won't notice the slight increase in overhead with
testForkGrouping
enabled, while larger projects would benefit substantially from the parallelism. And people can turn it off if necessary.Mill's been using it since 0.12.0 and it's been pretty robust, probably can make it the default in 0.13.0
The text was updated successfully, but these errors were encountered: