Page History

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

Understanding OpenJFX Unit tests.

...

When creating a new unit test, think about some of the special cases listed above and talk to the team about any special needs.

Classpath

Gradle configures the classpath for each of the test modules. This classpath includes

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

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

Fun in a modular world

With the addition of modules in JDK9, there are some additional details that must be understood when dealing with the unit tests.

...

To access a class in this package, we will need to use an addExport option to override the default package protections for the test. Also note that package specifications do not include any sub packages - each must be explicitly mentioned.

Any packages not mentioned in the module info cannot be used for a shim, because the JDK does not allow addExport unreferenced packages. In these cases, you will have to get clever with your shims, placing the test visible one 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:

...

By default, java will look for the module shared libraries in the JDK, which may mean problems if was are trying to use the libraries we just built. To access those libraries, we need to use -Djava.library.path=build/sdk/lib/_the_right_arch_ to find them

Capturing our classpath

During the build test task, a @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.

GradleJUnitWorker

Gradle 2.11 does not understand JDK 9 modules. Normally, gradle uses its own JUnit worker to process the test environment, particularly the classpath before running each of the tests. GradleJUnitWorker was created to workaround many of the issues that were encountered. This workaround is launched by gradle, and it in turn launches the gradle JUnit worker with the appropriate JDK9 modular arguments.

Toggling worker.debug

In build.gradle, there is a toggle that can be used to create additional output on 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.

systemProperties 'worker.debug': false

And 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:(coming soon). This can be useful when debugging a single test class:

jdk-9/bin/java \

 -Xpatch:build/testing/modules \

 @tests/system/src/test/addExports \

 @build/testing/classpath_systemTests.txt \

 -Djava.library.path=build/sdk/lib/amd64 \

  org.junit.runner.JUnitCore \

  test.sandbox.SandboxAppTest