The clustertest framework is implemented in Java, where tests
are implemented in the interpreted JavaScript language. The use of
Java made it much easier to implement tests involving concurrent
activities, both in terms of inducing test load, and in, concurrently
changing configuration of the replication cluster.

This framework makes use of libraries from several other open source projects:

js.jar

This is for org.mozilla.javascript, the Mozilla JavaScript interpreter

junit-4.8.1.jar

JUnit, a unit test framework.

log4j-1.2.15.jar

Log4J is a popular Java-based framework for generating event
logs.

postgresql-8.4-701.jdbc3.jar

This is the PostgreSQL JDBC driver.

To build the framework, it is necessary to have a Java compiler
and the build tool, Ant, installed. To
build all the .jar files used by the framework,
one will run the command, with output similar to the following:

The DISORDER or DIStributed
ORDER test is intended to provide concurrency tests
involving a reasonably sophisticated schema to validate various
aspects of Slony-I behavior under concurrent load.

It consists of:

A schema for an inventory management application.

Major objects include customers, inventory items, orders, order lines, and shipments.

There are foreign key relationships between the various items,
as well as triggers that maintain inventory and customer balances.
Some of these relationships involve ON DELETE CASCADE, and
so some actions may induce large numbers of cascaded updates.

Stored procedures to induce creation of the various
sorts of objects, purchases, shipments, and additions and removals of
customers and products.

Some tests are intended to be run against replicas,
validating that balances add up. We believe that PostgreSQL applies
changes in a transactional fashion such that they will always
COMMIT leaving the visible state consistent;
certain of the tests look for inconsistencies.

There are JavaScript test scripts that induce all
sorts of manipulations of replication clusters to validate that
replication configuration changes succeed and fail as expected.

This file contains Java style properties indicating how to
connect to the various databases used by the DISORDER tests, including paths to
tools such as slon and slonik

The sample file is to be copied to
conf/disorder.properties, and customized to
indicate your local configuration. By using a
.sample file, a developer may run tests within a
Git tree, and not need to worry about their customizations interfering
with the "canonical" sample configuration
provided.

conf/java.conf.sample

This is a shell script containing a path indicating where the
clustertest Java code (e.g. - the
clustertest-coordinator.jar file) may be found. This is
also used, indirectly to determine where additional Java .jar files
such as the JDBC driver are located.

As with the disorder properties, above, this needs to be copied
to conf/java.conf, and customized to indicate one's own local
configuration.

conf/log4j.properties

See documentation for Log4J for more
details as to how this is configured; the defaults provided likely do
not need to be altered.

Similar to the Section 6.7.2.1 for DISORDER tests, there are three configuration parameters:

conf/slonyregress.properties.sample

This file contains Java style properties indicating how to
connect to the various databases used by the regression tests,
including paths to tools such as slon and slonik

The sample file is to be copied to
conf/slonyregress.properties, and customized to
indicate your local configuration. By using a
.sample file, a developer may run tests within a
Git tree, and not need to worry about their customizations interfering
with the "canonical" sample configuration
provided.

conf/java.conf.sample

This is a shell script containing a path indicating where the
clustertest Java code (e.g. - the
clustertest-coordinator.jar file) may be found.
This is also used, indirectly to determine where additional Java .jar
files such as the JDBC driver are located.