If you want a preliminary review of a WIP PR, then yes, announcing it
here is fine.
-- Kevin
On 2/26/2020 7:53 AM, Rony G. Flatscher wrote:
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>
