ant target

Comments

junit-clean

Remove any folders from previous junit runs through ant targets.

junit-all

Run all the functional tests. Intended to match suites.All but also adds some tests that require to be run in their own virtual machine. (requires explicit setting of the classpath)

junit-all-codeline-jars

Run junit-all automatically setting the classpath in a codeline to be the compiled jar files

junit-system-mini

Run a short version of any system tests that run under junit. Intended to be a quick check of Derby and the system test. (requires explicit setting of the classpath)

junit-system-mini-codeline-jars

Run junit-system-mini automatically setting the classpath in a codeline to be the compiled jar files

junit-single

Run a single test or suite that runs under junit. Set the system property derby.junit.testclass to the full classname of the test or suite you want to run. (requires explicit setting of the classpath)

junit-html

Converts the set of XML junit files in the current run into an HTML report. Used along with other junit-* targets. The index.html is found in the junit_timestamp folder

junitreport

Combination of junit-all and junit-html

Test Class

Run by junit-all

Comments

org.apache.derbyTesting.functionTests.suites.All

Yes, though the ant targets contain logic that matches the contents of suites.All rather than running suites.All directly.

Majority of the functional & unit tests, all intended to be run as a single Junit test run invocation. If details are needed on the tests included then look at the source and see what tests are included. Any test class run directly or indirectly by suites.All can be run as a standalone JUnit test, e.g. ...functionTests.tests.jdbcapi._Suites for all the JDBC API tests ...functionTests.tests.lang.MathTrigFunctionsTest to just test the math trig functions.

org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadTest

Yes, via target junit-autoloadtest

Each test class needs to be in a separate JUnit run in its own JVM as these are testing the auto-loading of JDBC drivers at JVM startup.

org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCDriversEmbeddedTest

org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCDriversClientTest

org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCDriversAllTest

org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite

Yes

Upgrade tests, included in suites.All but has special requirements for accessing old released. The caller can set the system property derbyTesting.oldReleasePath to a folder containing previous releases. See the source comments for upgradeTests._Suite for details on how the folder is expected to look. If the property is not set then the tests will pick the old released jar files directly from Apache's SVN, if offline or the repo is not available then the tests will fail. If the tests are to be run frequently then providing a local copy of the jars using derbyTesting.oldReleasePath is recommended. See the source comments for details on how to checkout the old release jar files locally. If running the tests via the ant targets then derbyTesting.oldReleasePath can be set as an ant proprty, e.g. in ant.properties

org.apache.derby.PackagePrivateTestSuite

No, run target 'pptesting' manually.

These tests run against package private classes and/or methods. Therefore, they have to be in the same package as the class they are testing. Because we do not want to distribute test code in the production code jars, these tests are currently only intended to be run against the classes-directory. Most of these tests are rather low-level.

Test Class

Run by junit-all

Comments

org.apache.derbyTesting.perf.basic._Suite

No

All the basic performance tests will get run

org.apache.derbyTesting.system.oe.run.Populate

No

Run the load phase including schema creation for the Order Entry benchmark