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