[jira] (SUREFIRE-1070) Forks would complete more uniformly if slow tests aren't run last

["Andreas Gudian (JIRA)" <ji...@codehaus.org>]

    [ https://jira.codehaus.org/browse/SUREFIRE-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345139#comment-345139 ] 

Andreas Gudian commented on SUREFIRE-1070:
------------------------------------------

The feature described in SUREFIRE-726 would help here: it would allow you to do your own custom sorting of test classes. We should really take on doing that thing one day, as we already have a lot of such issues filed around here... ;-)

> 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)