Page History

...

OpenJFX contains many JUnit based unit tests that can be run using 'gradle test' as part of a build.

...

Source locations

There are two primary locations to find the unit tests in the repository:

...

• they use the same extension classloader as the core classes
• they provide test entry points that circumvent restrictions on API visibility for unit testing. 
• they usually must live in the same package as the API they are exposing .(to avoid package private scope)
• they cannot use classes on the Application class loader - like the JUnit API (no import org.junit.* for example)
• with modules - they must live in a package referenced in by the module-info for the class.

In the OpenJFX repository, the shims are any test class that does not reside in the test package.

It is best to keep these shim classes as simple as possible, retaining reserving as much of the test logic in the Unit test classes as possible. Sometimes however, it makes sense to add more than just an accessor method, adding utility routines that may be easier to write from within the protected package.In the OpenJFX repository, the shims are any test class that does not reside in the test package.

With modules, the shim classes must live in a package already referenced in the module-info for the class, even if the package is not public. The addExports option can be used to loosen module restrictions, but not expose a package that is not already listed.

...

The unit tests run with the application class loader, and not the extension class loader as the core classes are.

With modules, they usually are the unit tests  run in the "unnamed" module by default (. OpenJFX does not create a "test" module containing the tests).

All unit tests must be:

• JUnit tests
• part of the test package hierarchy (i.e. package test.*).
• Certain tests are optionally selected by gradle using run time options.
• @ignore(bug #) can be used to disable a test

Optional Tests with gradle toggles.

• -PFULL_TEST=true - long running tests, robot tests, or ones that flash windows making the host difficult to use
• -PUSE_ROBOT=true - enable Robot based tests
• -PHEADLESS_TEST=true - enable headless tests on some platforms
• -PAWT_TEST=true - enable AWT related tests
• -PUNSTABLE_TEST=true - enable tests tagged as unstable

...

• use the documented public API
• one of the shim classes
• in a few cases may be able to directly use internal API (like com.sun.*) classes with the right module addExport

(mention @ignore ? unstable test pattern ?)

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

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

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.

@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:

        assumeTrue(Boolean.getBoolean("unstable.test"));

Some tests are platform specific. These can be toggled with a line like this:

        assumeTrue(PlatformUtil.isMac() || PlatformUtil.isWindows());

Classpath

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

...

During the build test task, a 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 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 it to pass through stdout/stderr from the worker process).

systemProperties 'worker.debug': false

...