Page History

...

Currently all of the Robot based tests are ing in systemTests, and must live in the test.robot package.

Running a single test

Often a single test can be run for debugging using the --tests option to gradle:

gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.embed.swing.RT32570Test

In this example, we want to run a single test in systemTests, which needs to be enabled with FULL_TEST

Disabling/Optional Unit Tests

There are times when a Unit test must be conditional or disabled. Here are some of the tricks for doing that.

@ignoreThe annotation @Ignore("bug_id")  is used to disable a unit test on all platforms,

Unstable tests can be toggled using the conditions from within the test:

...

• the JUnit jars
• each of the dependent modules (graphics has base tests in its classpath)

The dependent modules tests test classes are rarely used, but do contain items like the stub toolkit, so must be included.

...

Any packages not mentioned in the module info cannot be used for a shim, because the JDK does not allow addExport of unreferenced packages. In these cases, you will have to get clever with your shims, placing the test visible one shim in a visible package, perhaps calling a second layer of shim in a hidden package.

Each of the build modules in OpenJFX has an addExports file that is imported using @argfile into the test invocation. The addExports file contains entries that export packages that are not public so that the unit tests in the unnamed module can see them. Here is an excerpt from one of the files:

...

    -XaddExports:

...

javafx.base/com.sun.javafx.collections=ALL-UNNAMED

...

    -XaddExports:
...
javafx.
...
base/com.sun.javafx.
...
property=ALL-UNNAMED
    -XaddExports:javafx.base/com.sun.javafx=ALL-UNNAMED
...
    -XaddExports:
...
javafx.
...
base/com.sun.javafx.
...
event=ALL-UNNAMED
...
And example error, that indicates a missing export:
java.lang.IllegalAccessError: class test.javafx.beans.Person (in unnamed module @0x22a67b4) cannot access class com.sun.javafx.property.PropertyReference (in module javafx.base) because module javafx.base does not export com.sun.javafx.property to unnamed module @0x22a67b4
...
Building an Xpatch
As part of the modular test build, we need to create a directory containing the freshly built core classes with the shim classes added in. This combined mix of classes can be used with the Xpatch command to override the modules in the JDK.
...
Capturing our classpath
During the build gradle test task, an @argfile form of the test classpath is created for each of the modules. This can be used for reference or with manual command lines. An example of this file is: build/testing/classpath_graphics.txt.
...
In build.gradle, there is a toggle that can be used to create additional output on from GradleJUnitWorker showing the command lines used to launch tests. This currently affects 
 GradleJUnitWorker.java and the system Sandbox tests. Modify this line (temporarily), and run tests with the gradle -info option. (The -info option to gradle enabled enables it to pass through stdout/stderr from the worker process).
...
For our current JUnit tests, this only applies to the Sandbox tests in :systemtests. To permit the Xpatch classes to operate properly, we generate a java.policy file for the core FX classes in the Xpatch modules. This java.policy file (build/testing/java.patch.policy) can be used standalone if no additional permissions are needed, or must be combined with the desired additional permissions to form a single java.policy file. The Sandbox tests combine the permissions in the text file indicated by the property worker.patch.policy with the test permissions, and use the resulting file when invoking the test app.
...
An example modular manual command line
The following is an example command line that can run a junit test from within a built Linux OpenJFX modular tree. This can be useful when debugging a single test class:
...