You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Commit Tag Bot (JIRA)" <ji...@apache.org> on 2013/03/22 17:45:20 UTC
[jira] [Commented] (LUCENE-4360) Support running the same test
suite multiple times in parallel
[ https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610915#comment-13610915 ]
Commit Tag Bot commented on LUCENE-4360:
----------------------------------------
[branch_4x commit] Dawid Weiss
http://svn.apache.org/viewvc?view=revision&revision=1381124
LUCENE-4360: Support running the same test suite multiple times in parallel.
> Support running the same test suite multiple times in parallel
> --------------------------------------------------------------
>
> Key: LUCENE-4360
> URL: https://issues.apache.org/jira/browse/LUCENE-4360
> Project: Lucene - Core
> Issue Type: New Feature
> Components: general/test
> Reporter: Dawid Weiss
> Assignee: Dawid Weiss
> Priority: Trivial
> Fix For: 4.0, 5.0
>
> Attachments: quickhack.patch
>
>
> The current "test execution multiplier" or:
> {code}
> -Dtests.iters=N
> {code}
> generates multiple tests (method executions) under a test class (suite). All these tests, however, are bound to a single class so they must run sequentially and on a single JVM (because of how JUnit works -- nesting of rules, class hooks, etc.).
> Mark pointed out that if somebody has a multi-core CPU then it'd be nice to be able to run a single suite in parallel, possibly in combination with tests.iters (so that a single test method is executed X times on Y parallel JVMs).
> This is surprisingly easy with the randomized runner because it currently accepts "duplicate" suite names and will load-balance them in a normal way. So, if one has Y cores (JVMs) then providing a suite name X times will result in X executions, balanced across Y JVMs.
> The only problem is how to "multiply" suite names. This can be done in a number of ways, starting from a custom resource collection wrapper and ending at a built-in code in the runner itself. I think the custom collection wrapper approach would be interesting, I'll explore this direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org