Ad suggested test unit for "JDK-8234959 FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV"

Rony G. Flatscher Rony.Flatscher at wu.ac.at
Wed Feb 26 15:53:42 UTC 2020


After studying [1], not sure whether one is supposed to announce a WIP here or not, so in doubt also
announcing the URL for the suggested test unit (part of the systemTests) for those interested in
checking it out: <https://github.com/openjdk/jfx/pull/123>.  To run the systemTests tests only one
can issue:

|    ./gradlew -PFULL_TEST=true :systemTests:test --tests ModuleLauncherTest|

This will include the suggested WIP test unit "testscriptapp1".

---rony

[1] "Contributing to OpenJFX": <https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md>


On 18.02.2020 14:25, Rony G. Flatscher wrote:
> For creating a test unit to test whether [1] is present or not, it is necessary to have a Java
> script engine to test again. As discussed in a different thread it is not advisable to use any
> concrete, existing Java script engine that is not part of the JDK. Therefore it becomes necessary to
> come up with a proper implementation of javax.script.ScriptEngine and
> javax.script.ScriptEngineFactory to serve for the sole purpose of testing.
>
> I have come up with such a "pseudo script engine" which will log each script invocation together
> with the script code, a copy of the ScriptContext in effect (for later inspection) and the time of
> invocation.
>
> For a test unit it is necessary to have this pseudo script engine loaded via the SPI to be able to
> use from a test application. For this one can define a
> "META-INF/services/javax.script.ScriptEngineFactory" file and/or a "module-info.java" file. In order
> to be as flexible as possible both approaches were chosen (also in mind that others may have a need
> for such a pseudo script engine for testing purposes). This implementation creates a module that
> contains a test application where the ideas and structures are modelled after the "systemTests"
> modules (many thanks to Keving Rushforts for pointing at that!).
>
> The test application will create a JavaFX application that processes some fxml file "demo_01.fxml"
> which defines the pseudo script engine to be used for executing all of the scripts defined in that
> file. The "start" method will fire the Button using  "btn.fire()", "btn.fireEvent( new ActionEvent()
> )", and "btn.fireEvent( new MouseEvent( ... ) )" to have the event scripts executed. As mentioned
> the pseudo script engine will log each invocation.
>
> Upon return of the "start" method the test application's main method will fetch the log of
> invocations from the pseudo script engine and then assert that the sequence of invocations, the
> scripts and the ScriptContext Bindings are correct with respect to some "demo_01.fxml". This not
> only asserts the proper existence of the entries "javax.script.filename" (also the proper values of
> the file names) and "javax.script.argv" in the engine Bindings, but also whether the global Bindings
> are correctly defined and their values (and types) are correct. These assertion tests are dependent
> on a) how FXMLLoader populates the ScriptContext Bindings and b) how the test case in form of the
> fxml-file and the supplied pseudo scripts is formulated.
>
> The test unit uses assertion methods of its own (like the other module based tests) and if it ends
> with an exit code of 0 it has passed. In the case of assertion errors (or unexpected errors) an
> appropriate error message with a stack trace is given and a non-zero exit code is returned via
> "System.exit()" (again modeled after/copied from the other module tests).
>
> To make this test unit as simple as possible the module includes the pseudo script engine (it is not
> a separate module). It needs to be run on its own JVM (as is the case with the other module tests).
>
> Any comments, questions, suggestions?
>
> ---rony
>
> [1] "JDK-8234959 FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV":
> <https://bugs.openjdk.java.net/browse/JI-9062887>
>


More information about the openjfx-dev mailing list