[
https://jira.codehaus.org/browse/SUREFIRE-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343335#comment-343335
]
NAthan McDonald commented on SUREFIRE-1070:
-------------------------------------------
documentation says "Balanced is only relevant with parallel=classes", but we
aren't using parallel, only forkCount.
Tried this anyway, using balanced does seem to actually run a bit quicker for
subsequent runs, but this still does not solve our problem. Our CI server does
a fresh checkout/build each time, so the statistics file which improves future
runs doesn't come into effect.
> Forks would complete more uniformly if slow tests aren't run last
> -----------------------------------------------------------------
>
> Key: SUREFIRE-1070
> URL: https://jira.codehaus.org/browse/SUREFIRE-1070
> Project: Maven Surefire
> Issue Type: Improvement
> Reporter: NAthan McDonald
> Priority: Minor
>
> Have started using forkCount to use multiple forks when running unit/IT tests.
> We've got a handful of slow tests, but without more than 1 fork, makes no
> difference in the order they run.
> However once we forked (we use 4 forks, on 8 cores), I noticed one or two
> forks run longer than the others, completing our slow tests.
> Ideally we want each fork to execute in the same time, but this presents
> packing problem.
> At simplest term, seems improvements would be achieved if we ensured we ran
> slow tests first, dividing these up among the initial forks. I've got this
> as a workaround, by configuring runOrder to be alphabetical, and
> renaming/moving slow tests to an aaslow package, and can see performance
> improvements. This is not ideal though.
> For a few known slow classes, could have a means to specify them. Otherwise
> was thinking would be nice if we annotated slow tests with junit categories,
> and then could specify forked mode to run certain categories first. Guess
> the solution is up for debate, but this does provide significant gains in
> performance would be nice for a way to tweak the runner without having to
> move tests to different paths.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
