[
https://issues.apache.org/jira/browse/SUREFIRE-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koen Serneels updated SUREFIRE-1237:
------------------------------------
Description:
I have a Maven module in which I grouped test classes based on their package
into different TestNG suite files. The different suite's are listed in the
plugin config using <suiteXmlFiles>. The tests identified by the suites are ran
sequentially ootb by surefire. With the current version it is already possible
to run the tests within the suites in parallel using multiple threads (within a
single JVM).
However, in my situation I need them to run forked in different JMVs. So what I
want is a JVM fork per suite XML file and not multiple threads. While there
are also fork options, they don't seem to work in combination with suite XML
files (but rather with methods and or test classes).
So, what I'm after is an option that creates a pool of forked JVM's which takes
care of running the available suite XML files. For ex. "<fork>suites</fork>
<maxFork>8<maxFork>". Each fork will then execute it's test (as identified by
the suite XML file) in sequence. So for example, in the config given above,
there will be 8 forked JVM's. When I have 10 suite XML files, each JVM will
start working on the tests identified by its assigned suite XML. So, JVM1 will
run all tests (sequentially) identified by suite XML1. In parallel, JVM2-8 will
do the same thing for their assigned suite XML. From the moment a forked JVM is
done processing its suite XML file it will start on the next one until they are
all processed.
was:
At the moment I grouped the test classes of a Maven module into different
TestNG suite files based on some criteria. The different suite's are ran
sequentially ootb by surefire. With the current version it is possible to run
the suites in parallel using multiple threads (using a single JVM).
However, in my situation I need them to run forked in different JMVs per suite
XML file. While there are also fork options, they don't seem to work icw suite
XML files. So, what I want is that tests are execute sequentually in each
forked JVM. So for example, JVM1 will work on all tests contained by suite XML
1 (running them sequentially). Then in parallel, JVM2,3,4 etc will do the same
thing for tests contained in there assigned suite XML file.
> Running suites forked
> ---------------------
>
> Key: SUREFIRE-1237
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1237
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
> Affects Versions: 2.19.1
> Reporter: Koen Serneels
>
> I have a Maven module in which I grouped test classes based on their package
> into different TestNG suite files. The different suite's are listed in the
> plugin config using <suiteXmlFiles>. The tests identified by the suites are
> ran sequentially ootb by surefire. With the current version it is already
> possible to run the tests within the suites in parallel using multiple
> threads (within a single JVM).
> However, in my situation I need them to run forked in different JMVs. So what
> I want is a JVM fork per suite XML file and not multiple threads. While
> there are also fork options, they don't seem to work in combination with
> suite XML files (but rather with methods and or test classes).
> So, what I'm after is an option that creates a pool of forked JVM's which
> takes care of running the available suite XML files. For ex.
> "<fork>suites</fork> <maxFork>8<maxFork>". Each fork will then execute it's
> test (as identified by the suite XML file) in sequence. So for example, in
> the config given above, there will be 8 forked JVM's. When I have 10 suite
> XML files, each JVM will start working on the tests identified by its
> assigned suite XML. So, JVM1 will run all tests (sequentially) identified by
> suite XML1. In parallel, JVM2-8 will do the same thing for their assigned
> suite XML. From the moment a forked JVM is done processing its suite XML file
> it will start on the next one until they are all processed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
