Running the full functional testsuite

1. Check out and compile the head (step 1. and 2. from Building JBoss Messaging)

2. Create the Messaging artifacts

     cd jboss-head/jms
     ant clean
     ant

3. Run the functional testsuite

     cd jboss-head/jms/tests
     ./build.sh report

The results can be found under tests/output/reports/html.

Running tests using an arbitrary host name (or IP address)

Modify the test.bind.address property in tests/build.xml (or on VM's command line) to the host name or IP address associated with the interface you want to use.

Running single tests from command line (without ant)

tests/bin/runtest makes easy to run single tests or groups of tests from command line, without the added overhead of starting ant.

In order to run a single unit test, add the TARGET_CLASS and TARGET_TEST variables to your environment, where TARGET_CLASS is the fully qualified class name of the junit test you want to run and TARGET_TEST is the name of the individual test.

Example:

export TARGET_CLASS=org.jboss.test.messaging.jms.MessageConsumerTest
export TARGET_TEST=testReceive

You can have more than one single individual test in the same run, by specifying a comma-separated list of individual test names as the value of TARGET_TEST variable.

Example:

export TARGET_TEST=testSend,testReceive

TARGET_CLASS and TARGET_TEST can be configured as part of your environment (as shown above) or specified in tests/bin/.testrc.

Configuring persistence

The persitence support of the test container is configured by setting TEST_DATABASE to a configuration available in container.xml. You can set the TEST_DATABASE variable of your .testrc file, or you can define a new enviroment variable TEST_DATABASE in your shell. The environment variable value takes precedence over .testrc one.

For more details, see "Configuring Persistence Support".

Configuring serialization

The remoting serialization configured by setting TEST_SERIALIZATION to either "jboss" or "java". You can set the TEST_SERIALIZATION variable of your .testrc file, or you can define a new enviroment variable TEST_SERIALIZATION in your shell. The environment variable value takes precedence over .testrc one.

A .testrc example is available here. If the variables are set in both places, the environment variable setting takes precedence.

To run the test on command line:

     cd tests/bin
     ./runtest

To run the test in remote mode:

     ./runtest -remote [-remotedebug]

To run the test in debug mode:

     ./runtest -debug

Running clustered tests from command line (without ant)

Configure the TARGET_CLASS and TARGET_TEST as described previously.

To run the test in co-located clustered mode:

       ./runtest -clustered

In this particular situation, the whole cluster (and implicitly all messaging nodes) will live in the same VM. This mode might be useful when trying to follow and debug and invocation across the cluster. A debugger can be attached to the VM that runs the whole test and a message can be followed on its way from producer to consumer.

To run a co-located clustered test in debug mode:

      ./runtest -clustered -debug

The VM will start in debbuging/server mode, listening on shared memory address "runtest" and it will block until a debugger connects to it.

To run the test in remote clustered (different VM running different cluster nodes) mode:

       ./runtest -clustered -remote

In this configuration, each cluster node will run in its own VM, and the test client will run it a separate VM as well.

You can debug both the client and each cluster node in a remote configuration, by running:

       ./runtest -clustered -remote -debug

for the client, and for each cluster node individually:

       ./runtest -clustered -remote -remotedebug

(this will start the node 0 in debug mode; before running the command, you should start your debbuger in "listen" mode on the "rmiserver_0" shared memory address. The VM running node 0 will connect to it )

       ./runtest -clustered -remote -remotedebug 1

(this will start the node 1 in debug mode; before running the command, you should start your debbuger in "listen" mode on the "rmiserver_1" shared memory address. The VM running node 1 will connect to it )

       ./runtest -clustered -remote -remotedebug 2

(this will start the node 2 in debug mode; before running the command, you should start your debbuger in "listen" mode on the "rmiserver_2" shared memory address. The VM running node 2 will connect to it )

Configuring persistence support

The test framework connects to an actual database instance when performing persistence-related tests. By default, the ServiceContainer starts an in-VM HSQLDB instance, which is adequate for functional tests. However, HSQLDB cannot be used to produce reliable stress test results. In situations like this, the test fixture should be configured to connect to a reliable, out-of-process database.

The test framework persistence support is configured in tests/etc/container.xml.

To configure the test framework to use one of the already configured database instances, set the value of the <database> element to be one of the available database configurations.

Example:

   <container>
      <database>mysql</database>
      ...
   </container>

Note:  You can also specify the database configuration to use as value of the test.database system property. If test.database is used, it will take precedence over the value specified in container.xml.

A quick visual confirmation that tests use the intended database is provided by the test's log4j output:

     ...
     main 09:08:27,195 INFO  [ServiceContainer] remoting = "socket", database = "hsqldb"
     ...

Note 2: The preferred way of specifying the database to run functional tests with, when the tests are run as part of a tests/build.xml ant target, is to modify the definition of the functional.tests.database system property in tests/build.xml:

    <property name="functional.tests.database" value="hsqldb"></property>

Note 3: The preferred way of specifying the database to run stress tests with is to modify the definition of the stress.tests.database system property in tests/build.xml:

    <property name="stress.tests.database" value="mysql"></property>

Note 4: The preferred way of specifying the database to run individual runtest tests with is to modify the definition of TEST_DATABASE in .testrc

To enable access to an arbitrary database instance, add a <database-configuration> element, and then set that database configuration name as value for <database>

Example:

   <container>
      <database>myPostgresInstance</database>
      <database-configurations>
         ...

         <database-configuration name="myPostgresInstance">
            <url>jdbc:postgresql://localhost:5432/messaging</url>
            <driver>org.postgresql.Driver</driver>
            <isolation>TRANSACTION_READ_COMMITTED</isolation>
            <username>someUser</username>
            <password>somePassword</password>
         </database-configuration>
         ...
      <database-configurations>
   </container>

You also need to make sure that the database driver specified by the <driver> element is available in the test's classpath.

Atlanta QA Lab

• Go on dev03

      <database-configuration name="mysql">
         <url>jdbc:mysql://dev01-priv/messaging
         <driver>com.mysql.jdbc.Driver</driver>
         <isolation>TRANSACTION_READ_COMMITTED</isolation>
         <username>messaging</username>
         <password>messaging</password>
      </database-configuration>

       
       mysql -u messaging -h dev01-priv -p

Referenced by: