In this chapter we are going to see how to launch a JTR test you have written. You can choose among three different ways:

1. •you can use the provided JTR Ant tasks
   

2. •you can use the jtr.test.Test class main method
   

3. •you can use a class of yours
   

Note: in any case, please remember that JTR exits the JVM with code 0 if and only if any test failed, otherwise a code other than 0 is returned. This is useful when integrating JTR in a continuos integration process.

Using JTR ad-hoc Ant tasks

Since JTR 5 it is possible launching both active and passive JTR nodes by means of ad-hoc Ant tasks. Let’s see a couple of examples:

<target name="jtrun" depends="jar" description="Runs a JTR-test suite using the jtrun task">

  <taskdef name="jtrun" classname="jtr.ant.JtrRun" classpath="${run.classpath}"/>

  <jtrun classpath="${run.classpath}"

          jtr="config/jtr.xml"

          host="localhost"

          registryPort="2100"

          policy="config/java.policy"

          log4j="config/log4j.xml">

    <jvmarg value="-Dcom.sun.management.jmxremote"/>

  </jtrun>

</target>

With the snippet above we define a new target called jtrun which uses the jtr.ant.JtrRun Ant task. This task is meant for launching a JTR active node. It accepts the following attributes:

1. -jtr, the relative-path to the JTR configuration file (this is a compulsory attribute)
   

2. -host, the name of the host on which the active node is running or its IP-address (this attribute refers to the jtr.remote.test.host seen here)
   

3. -registryPort, the port on which the active node is listening (this attribute refers to the jtr.remote.test.port seen here)
   

4. -classLoaderPort, the port on which the server class-loader has to listen to (see here)
   

5. -outcomeCollectorPort, the port on which the active node is waiting for remote tests results to come (see here)
   

6. -policy, the relative-path to the SecurityManager configuration file (this is a compulsory attribute)
   

7. -log4j, the relative-path to the Log4J xml configuration file (this is a compulsory attribute)
   

Note: the jtr.ant.JtrRun Ant task also accepts any other sub-element accepted by the standard java Ant task.

<target name="passiveNode" description="Runs a JTR 5.0 passive node">

  <taskdef name="jtrpassive" classname="jtr.ant.JtrPassive" classpathref="run.classpath"/>

  <jtrpassive classpathref="run.classpath"

          host="localhost"

          registryPort="2100"

          policy="config/java.policy"

          log4j="config/log4j.xml">

    <jvmarg value="-Dcom.sun.management.jmxremote"/>

  </jtrpassive>

</target>

In the latter case the JTR Ant task we are using is of type jtr.ant.JtrPassive. Since this task is meant for running passive-nodes, it silently ignores any jtr configuration file you may specify. It accepts the following attributes:

1. -host, the name of the host on which the passive node is running or its IP-address (this attribute refers to the jtr.remote.test.host seen here)
   

2. -registryPort, the port on which the passive node is listening (this attribute refers to the jtr.remote.test.port seen here)
   

3. -testGatewayPort, the port on which the passive node is waiting for tests to launch locally (see here)
   

4. -policy, the relative-path to the SecurityManager configuration file (this is a compulsory attribute)
   

5. -log4j, the relative-path to the Log4J xml configuration file (this is a compulsory attribute)
   

Note: the jtr.ant.JtrPassive Ant task also accepts any other sub-element accepted by the standard java Ant task.

Compulsory JVM system properties

Independently of your choice, you must remember that the two following system properties (or their equivalent Ant task attributes) are required:

1. •jtr.test.Test.config: its value must be the path to the jtr.xml file describing the test-suite
   

2. •log4j.configuration: its value must be the path to the log4j.xml configuration file
   

Using the jtr.test.Test class main method

In this scenario you leverage on the main method exposed by the jtr.test.Test class to launch your test-suite. The best way you can work with this class is writing an Ant target like the following one:

<target name="jtr" depends="init">

    <java classname="jtr.test.Test" dir="./" fork="true">

        <classpath refid="${runtime.classpath}" />

        <!-- JTR standard properties -->

        <jvmarg value="-Djtr.test.Test.config=config/jtr.xml"/>

        <jvmarg value="-Dlog4j.configuration=config/log4j.xml"/>

        <!-- Required JVM properties for distributed testing -->

        <jvmarg value="-Djtr.remote.test.host=localhost"/>

        <jvmarg value="-Djava.security.policy=java.policy"/>

        <!-- Optional JVM useful property -->

        <jvmarg value="-Dcom.sun.management.jmxremote"/>

    </java>

</target>

In the above snippet, as you can see, the main class is the jtr.test.Test class. Skipping the classpath setting we can concentrate on the set JVM arguments.

First of all we have the two properties introduced before, required for identifying the right jtr.xml file describing the JTR test-suite and for properly configuring the Log4J sub-system.

The other two properties are required if you intend to perform distributed testing sessions too. For a more detailed description of those properties, please go here.

Using your own classes

You can even a class you have written on your own for launching a JTR test-suite. Acting this way you simply have to instantiate an object of type jtr.test.Test and call its run() / start() method according to your needs.

Note: even in this case, please remember to set the JVM properties discussed so far.

Next step: using the JTRConsole