You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that #6 is complete, we should be able to provide true unit-tests for individual parts and visuals
The plan was to use TestFX for this; however it is currently not possible due to Releng limitations.
E(fx)clipse dynamically makes JavaFX available on the Module Path via JavaFX Jars shipped through a P2 Repository, which allows to use JavaFX in a very transparent manner for the end-user (He doesn't need to mess with his VM's Modules manually)
However, the OSGi version of TestFX uses some package-imports to javafx packages, which can only be resolved by OSGi if these modules are actually available on the module path. The problem is that this isn't compatible with E(fx)'s approach, making it impossible to install TestFX (e.g. via P2).
A solution might be to require having OpenJFX available at build time, and adding it explicitly on the Module Path (As expected by OSGi and TestFX). This is less flexible that E(fx)'s dynamic approach, but it would only be a requirement for developers and build servers. However, I've not tried this approach yet and I don't know if it would actually work
The text was updated successfully, but these errors were encountered:
It provides "Robot-like" interaction commands (move mouse, click here, press that) that are implemented by synthesizing corresponding JavaFX events, so that you do not depend on the actual input devices.
Hi Mathias and Tamas,
Thanks for the pointers. I've been using TestFX (https://github.com/TestFX/TestFX) successfully in the past. It provides some high-level FX Robot features to emulate user input. However, starting with Java 9, the module system makes it difficult to use with E(fx)clipse, since both projects are using different approaches for working with Modules and OSGi. It might be possible to make it work somehow, but I had to give up for now.
The test class provided by GEF might be a good candidate for an alternative approach; I'll definitely look into it further
Now that #6 is complete, we should be able to provide true unit-tests for individual parts and visuals
The plan was to use TestFX for this; however it is currently not possible due to Releng limitations.
E(fx)clipse dynamically makes JavaFX available on the Module Path via JavaFX Jars shipped through a P2 Repository, which allows to use JavaFX in a very transparent manner for the end-user (He doesn't need to mess with his VM's Modules manually)
However, the OSGi version of TestFX uses some package-imports to javafx packages, which can only be resolved by OSGi if these modules are actually available on the module path. The problem is that this isn't compatible with E(fx)'s approach, making it impossible to install TestFX (e.g. via P2).
A solution might be to require having OpenJFX available at build time, and adding it explicitly on the Module Path (As expected by OSGi and TestFX). This is less flexible that E(fx)'s dynamic approach, but it would only be a requirement for developers and build servers. However, I've not tried this approach yet and I don't know if it would actually work
The text was updated successfully, but these errors were encountered: