TestFX – Current State and Future

If you have complex applications, you should test them. Especially GUIs. If not, you will have long release test cycles and in the worst case an unmaintainable application. If you do serious application development with JavaFX, you will end up using TestFX .

It was pretty silent around TestFX in the last year and some people were wondering, whether it is still maintained or not. This was an important question, especially on JavaFX trainings I gave. The reason for this perception is, that version 4 of TestFX has been in the alpha state now for one year.

This interview with Benjamin Gudehus will answer the core question: When is the release of TestFX 4?

Hi Benjamin, in the last years you are one of the most active contributors in the TestFX project, tell us something about you.

Hi Alex! My first programming experience was in BASIC on a Commodore VIC 20. Later I used the Amiga Workbench, drew designs of VCR remote controls and maps of my home town on paper. This particulary shaped my later interests in programming, user interfaces and digital cartography.

I use Java, Groovy, and Kotlin for desktop applications. Python for scientific computing to keep me sane (or insane, this depends from which perspective). I once used Ruby, when it was en vogue, now I use JavaScript and TypeScript for web technology.

Your first commit was on the 12 Jan 2014. Why did you start contributing?

I evaluated the situation of Swing’s open-source ecosystem back in December 2013. The lack of activity of many abandoned projects (SwingX, JSR 296, …) as well as the difficult to reach source code and documentation was disappointing. Around Christmas Eve I found a screenshot of dialogs that use the Modena theme – now the default theme for JavaFX. It took me a while to realize, that JavaFX since the 2.0 release actually is not only a rich internet application platform – which was prominently stated in JavaFX documentation and on Wikipedia, back then – but the third-generation GUI toolkit for desktop Java.

With a shiny new early access build of Java 8 installed on my machine, there was only one important thing missing: a (decent) GUI testing framework. This was TestFX and the clean and simple syntax impressed me the very first moment I saw it. Some difficulties to integrate TestFX with the Spock specification framework led to a reimplementation of TestFX as a prototype in the Groovy programming language, which was by the way an excellent way to understand the internals of TestFX.

Now, to come back to your question, I started contributing, because I saw that the prototype was a reasonable improvement over the internal architecture of TestFX and I wanted to receive feedback for this new implementation. This led to a huge step-by-step refactoring of TestFX 3 in Java. It turned out, that this was a good idea, I gathered a lot of feedback from TestFX’s existing internal test suite and the architecture was improved, which was really needed in order to add more features later.

What are the plans for TestFX 4?

We’ll see improvements in terms of flexibility. Previously TestFX was tightly coupled to JUnit, now you can use other testing frameworks, since the architecture was modularized. JavaFX fixtures under test are not restricted to root nodes anymore, you can also use scenes, stages or whole applications.

A difficult task was to keep the concise and elegant API of TestFX 3, but allow to modify the assumptions it makes. Per default we query scene nodes via CSS selector and for simple cases this is enough. But if we need more elaborate queries, for instance to interact with a color from the color picker or to verify the data of a table cell, we can use the new node query API.

The new version will support Java 8 lambdas and JavaFX 8 controls. It will also support headless testing using Monocle, which allows using TestFX on CI server configurations without window manager.

### TestFX 4
public class DesktopPaneTest extends ApplicationTest {
    public void start(Stage stage) {
        Scene scene = new Scene(new DesktopPane(), 800, 600);

    public void should_drag_file_into_trashcan() {
        // given:
        rightClickOn("#desktop").moveTo("New").clickOn("Text Document");

        // when:

        // then:
        verifyThat("#desktop", hasChildren(0, ".file"));
### TestFX 3
class DesktopTest extends GuiTest {
  public Parent getRootNode() {
    return new Desktop()

  public void shouldBeAbleToDragFileToTrashCan() {
    // GIVEN
    rightClick("#desktop").move("New").click("Text Document")

    // WHEN

    // THEN
    verifyThat("#desktop", contains(0, ".file"));

What are you currently working on?

Now that node queries are more flexible, I need to improve queries for the geometrical bounds of nodes and points within these bounds. For mouse interactions we assume the absolute screen position of a point within a visual node. This makes sense for mouse interactions, but these methods are reused for node state verification. So for example we couldn’t verify whether a node is visible or the bounds of a node within a scene or a parent node. This is very critical for some applications. It is also an integral part of TestFX, so we need to modify it with care. This is actually the last planned big change before the next major release.

When is the planned release of TestFX 4?

December 23, 2015 for beta release. Final release tentatively in Q1 2016.

We use TestFX in every project we do for our customers – do you have a feeling how often TestFX is used in production?

Wow, that’s very great. It is difficult for me to estimate rough figures how much TestFX is used in the industry. The thing is, there is much more participation on the TestFX mailing list and GitHub project page from e.g. people in academia. These are my primary communication channels. However, from direct emails I receive I know there is much more interest in the industry. It is important, that SmartBear started this project and that it is written completely in Java.

What are you doing with JavaFX?

We work with geographical information systems (GIS). Our application consists of three parts: it uses the GIS to visualize and interact with geographical maps, multiple relational database schemas whose data is linked to the graphical data and a scripting part which allows sophisticated lookup and modification of geometries and data.

We started migration from Swing to JavaFX and developed our own small GIS as replacement for the previous Swing-based GIS. JavaFX suits great, because we it not only allows display of data forms (with lists, tables and text fields), but also to display cartographic data (with shape paths).

Testing requires performance and conformance tests. For performance we use the renderer duration and for conformance we use the perceptional difference between the renderer’s output and expected images. We seek to contribute these testing features in one of the next releases of TestFX.

Thank you Benjamin for this interview and your good work for the JavaFX community.

You get the source code here: TestFX on Github

Alexander Casall works as a software developer at the Saxonia Systems AG in Dresden, Germany and his focus is with the implementation of modern multi-touch applications (JavaFX) and also the iOS Development (www.buildpath.de). Alexander publishes articles in journals, speaks at conferences (JavaOne, JAX, W-JAX) and is a speaker in various User Groups.

Twitter Xing