[jboss-jira] [JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12930739#comment-12930739 ] 

Bela Ban commented on JGRP-1728:
--------------------------------

We might be able to get rid of the XML suite definition files altogether ! Below is a crude example of how to run target {{functional}} with 10 threads (hard-coded). This would of course have to be changed in the {{runtest}} macro itself, but this shows it actually works.

{code:xml}
    <target name="run" depends="define-testng-task">
        <testng classpathref="jg.classpath"
                usedefaultlisteners="false"
                groups="functional"
                excludedgroups="broken"
                timeOut="120000"
                outputdir="@{outputdir}"
                listeners="org.jgroups.util.JUnitXMLReporter"
                timeout="${unittest.timeout}"
                verbose="${test.verbose}" threadcount="10"
                parallel="methods"
                >
            <classfileset dir="${compile.dir}"/>
            <!--<xmlfileset dir="${testng.conf.dir}" includes="@{testng.xmlfile}"/>-->
            <sysproperty key="test.suffix" value="@{testname.ext}"/>
            <sysproperty key="INITIAL_MCAST_ADDR" value="@{initial.mcast.addr}"/>
            <sysproperty key="INITIAL_MCAST_PORT" value="@{initial.mcast.port}"/>
            <sysproperty key="INITIAL_TCP_PORT" value="@{initial.tcp.port}"/>
            <sysproperty key="tcp.recv_buf_size" value="@{tcp.recv.buf.size}"/>
            <sysproperty key="tcp.send_buf_size" value="@{tcp.send.buf.size}"/>
            <jvmarg value="-Djgroups.bind_addr=${jgroups.bind_addr}"/>
            <jvmarg value="-Djgroups.tcpping.initial_hosts=${jgroups.tcpping.initial_hosts}"/>
            <jvmarg value="-Djgroups.tunnel.gossip_router_hosts=${jgroups.tunnel.gossip_router_hosts}"/>
            <jvmarg value="-Dtests.tmp.dir=${tmp.dir}"/>
            <jvmarg value="-Dlog4j.configuration=file:${conf.dir}/log4j.properties"/>
            <jvmarg value="-Dlog4j.configurationFile=${conf.dir}/log4j2.xml"/>
            <jvmarg value="-Djava.net.preferIPv4Stack=${java.net.preferIPv4Stack}"/>
            <jvmarg value="-Djava.net.preferIPv6Addresses=${java.net.preferIPv6Addresses}"/>
            <jvmarg value="-Xms400M"/>
            <jvmarg value="-Xmx800M"/>
        </testng>
    </target>
{code}
                
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
>                 Key: JGRP-1728
>                 URL: https://issues.jboss.org/browse/JGRP-1728
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.

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