Simple and clean testing for JavaFX.

Last update: Dec 28, 2022

Related tags

Overview

TestFX

Simple and clean testing for JavaFX.

TestFX requires a minimum Java version of 8 (1.8).

Documentation

See the Javadocs for latest master.
See the changelog CHANGES.md for latest released version.

Features

A fluent and clean API.
Flexible setup and cleanup of JavaFX test fixtures.
Simple robots to simulate user interactions.
Rich collection of matchers and assertions to verify expected states of JavaFX scene-graph nodes.

Support for:

Java 8/9/10/11+
Multiple testing frameworks (JUnit 4, JUnit 5, and Spock).
Hamcrest matchers or AssertJ assertions (or both!).
Screenshots of failed tests.
Headless testing using Monocle.

Gradle

To add a dependency on TestFX using Gradle, use the following:

dependencies {
    testCompile "org.testfx:testfx-core:4.0.16-alpha"
}

Java 11+

Beginning with Java 11, JavaFX is no longer part of the JDK. It has been extracted to its own project: OpenJFX. This means, extra dependencies must be added to your project.

The easiest way to add the JavaFX libraries to your Gradle project is to use the JavaFX Gradle Plugin.

After following the README for the JavaFX Gradle Plugin you will end up with something like:

plugins {
    id 'org.openjfx.javafxplugin' version '0.0.8'
}

javafx {
    version = '12'
    modules = [ 'javafx.controls', 'javafx.fxml' ]
}

Test Framework

Next add a dependency corresponding to the testing framework you are using in your project. TestFX currently supports JUnit 4, JUnit 5, and Spock.

JUnit 4

dependencies {
    testCompile "junit:junit:4.13-beta-3"
    testCompile "org.testfx:testfx-junit:4.0.16-alpha"
}

JUnit 5

dependencies {
    testCompile 'org.junit.jupiter:junit-jupiter-api:5.5.1'
    testCompile "org.testfx:testfx-junit5:4.0.16-alpha"
}

Spock

dependencies {
    testCompile "org.spockframework:spock-core:1.3-groovy-2.5"
    testCompile "org.testfx:testfx-spock:4.0.16-alpha"
}

Matcher/Assertions Library

Finally you must add a dependency corresponding to the matcher/assertions libraries that you want to use with TestFX. TestFX currently supports Hamcrest matchers or AssertJ assertions.

Hamcrest

testCompile group: 'org.hamcrest', name: 'hamcrest', version: '2.1'

AssertJ

testCompile group: 'org.assertj', name: 'assertj-core', version: '3.13.2'

Maven

To add a dependency on TestFX using Maven, use the following:

<dependency>
    <groupId>org.testfx</groupId>
    <artifactId>testfx-core</artifactId>
    <version>4.0.16-alpha</version>
    <scope>test</scope>
</dependency>

Java 11+

Beginning with Java 11, JavaFX is no longer part of the JDK. It has been extracted to its own project: OpenJFX. This means, extra dependencies must be added to your project.

The easiest way to add the JavaFX libraries to your Maven project is to use the JavaFX Maven Plugin.

After following the README for the JavaFX Maven Plugin you will end up with something like:

<dependencies>
    <dependency>
        <groupId>org.openjfx</groupId>
        <artifactId>javafx-controls</artifactId>
        <version>12.0.2</version>
    </dependency>
</dependencies>

<plugins>
    <plugin>
        <groupId>org.openjfx</groupId>
        <artifactId>javafx-maven-plugin</artifactId>
        <version>0.0.3</version>
        <configuration>
            <mainClass>hellofx/org.openjfx.App</mainClass>
        </configuration>
    </plugin>
</plugins>

Have a look at Maven Central's org.openjfx entry for an overview of available modules.

Test Framework

Next add a dependency corresponding to the testing framework you are using in your project. TestFX currently supports JUnit 4, JUnit 5, and Spock.

JUnit 4

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13-beta-3</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testfx</groupId>
    <artifactId>testfx-junit</artifactId>
    <version>4.0.16-alpha</version>
    <scope>test</scope>
</dependency>

JUnit 5

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-api</artifactId>
    <version>5.5.1</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testfx</groupId>
    <artifactId>testfx-junit5</artifactId>
    <version>4.0.16-alpha</version>
    <scope>test</scope>
</dependency>

Spock

<dependency>
    <groupId>org.spockframework</groupId>
    <artifactId>spock-core</artifactId>
    <version>1.3-groovy-2.5</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testfx</groupId>
    <artifactId>testfx-spock</artifactId>
    <version>4.0.16-alpha</version>
    <scope>test</scope>
</dependency>

Matcher/Assertions Library

Finally you must add a dependency corresponding to the matcher/assertions libraries that you want to use with TestFX. TestFX currently supports Hamcrest matchers or AssertJ assertions.

Hamcrest

<dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest</artifactId>
    <version>2.1</version>
    <scope>test</scope>
</dependency>

AssertJ

<dependency>
    <groupId>org.assertj</groupId>
    <artifactId>assertj-core</artifactId>
    <version>3.13.2</version>
    <scope>test</scope>
</dependency>

Examples

Hamcrest Matchers

TestFX brings along a couple of custom Hamcrest matchers in package org.testfx.matcher.*.

AssertJ based Assertions

TestFX uses its own AssertJ based assertion implementation class: org.testfx.assertions.api.Assertions.

JUnit 4 with Hamcrest Matchers

import org.junit.Test;
import org.testfx.api.FxAssert;
import org.testfx.framework.junit.ApplicationTest;
import org.testfx.matcher.control.LabeledMatchers;

import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class ClickableButtonTest_JUnit4Hamcrest extends ApplicationTest {

    private Button button;

    /**
     * Will be called with {@code @Before} semantics, i. e. before each test method.
     */
    @Override
    public void start(Stage stage) {
        button = new Button("click me!");
        button.setOnAction(actionEvent -> button.setText("clicked!"));
        stage.setScene(new Scene(new StackPane(button), 100, 100));
        stage.show();
    }

    @Test
    public void should_contain_button_with_text() {
        FxAssert.verifyThat(".button", LabeledMatchers.hasText("click me!"));
    }

    @Test
    public void when_button_is_clicked_text_changes() {
        // when:
        clickOn(".button");

        // then:
        FxAssert.verifyThat(".button", LabeledMatchers.hasText("clicked!"));
    }
}

JUnit 4 with AssertJ based Assertions

import org.junit.Test;
import org.testfx.assertions.api.Assertions;
import org.testfx.framework.junit.ApplicationTest;

import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class ClickableButtonTest_JUnit4AssertJ extends ApplicationTest {

    private Button button;

    /**
     * Will be called with {@code @Before} semantics, i. e. before each test method.
     */
    @Override
    public void start(Stage stage) {
        button = new Button("click me!");
        button.setOnAction(actionEvent -> button.setText("clicked!"));
        stage.setScene(new Scene(new StackPane(button), 100, 100));
        stage.show();
    }

    @Test
    public void should_contain_button_with_text() {
        Assertions.assertThat(button).hasText("click me!");
    }

    @Test
    public void when_button_is_clicked_text_changes() {
        // when:
        clickOn(".button");

        // then:
        Assertions.assertThat(button).hasText("clicked!");
    }
}

JUnit 5

TestFX uses JUnit5's new extension mechanism via org.junit.jupiter.api.extension.ExtendWith. By using this, implementors are not forced anymore to inherit from ApplicationTest and are free to choose their own super classes.

It does also make use of JUnit5's new dependency injection mechanism. By using this, test methods have access to the FxRobot instance that must be used in order to execute actions within the UI.

JUnit 5 with Hamcrest Matchers

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.testfx.api.FxAssert;
import org.testfx.api.FxRobot;
import org.testfx.framework.junit5.ApplicationExtension;
import org.testfx.framework.junit5.Start;
import org.testfx.matcher.control.LabeledMatchers;

import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

@ExtendWith(ApplicationExtension.class)
class ClickableButtonTest_JUnit5Hamcrest {

    private Button button;

    /**
     * Will be called with {@code @Before} semantics, i. e. before each test method.
     *
     * @param stage - Will be injected by the test runner.
     */
    @Start
    private void start(Stage stage) {
        button = new Button("click me!");
        button.setId("myButton");
        button.setOnAction(actionEvent -> button.setText("clicked!"));
        stage.setScene(new Scene(new StackPane(button), 100, 100));
        stage.show();
    }

    /**
     * @param robot - Will be injected by the test runner.
     */
    @Test
    void should_contain_button_with_text(FxRobot robot) {
        FxAssert.verifyThat(button, LabeledMatchers.hasText("click me!"));
        // or (lookup by css id):
        FxAssert.verifyThat("#myButton", LabeledMatchers.hasText("click me!"));
        // or (lookup by css class):
        FxAssert.verifyThat(".button", LabeledMatchers.hasText("click me!"));
    }

    /**
     * @param robot - Will be injected by the test runner.
     */
    @Test
    void when_button_is_clicked_text_changes(FxRobot robot) {
        // when:
        robot.clickOn(".button");

        // then:
        FxAssert.verifyThat(button, LabeledMatchers.hasText("clicked!"));
        // or (lookup by css id):
        FxAssert.verifyThat("#myButton", LabeledMatchers.hasText("clicked!"));
        // or (lookup by css class):
        FxAssert.verifyThat(".button", LabeledMatchers.hasText("clicked!"));
    }
}

JUnit 5 with AssertJ Assertions

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.testfx.api.FxRobot;
import org.testfx.assertions.api.Assertions;
import org.testfx.framework.junit5.ApplicationExtension;
import org.testfx.framework.junit5.Start;

import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

@ExtendWith(ApplicationExtension.class)
class ClickableButtonTest_JUnit5AssertJ {

    private Button button;

    /**
     * Will be called with {@code @Before} semantics, i. e. before each test method.
     *
     * @param stage - Will be injected by the test runner.
     */
    @Start
    private void start(Stage stage) {
        button = new Button("click me!");
        button.setId("myButton");
        button.setOnAction(actionEvent -> button.setText("clicked!"));
        stage.setScene(new Scene(new StackPane(button), 100, 100));
        stage.show();
    }

    /**
     * @param robot - Will be injected by the test runner.
     */
    @Test
    void should_contain_button_with_text(FxRobot robot) {
        Assertions.assertThat(button).hasText("click me!");
        // or (lookup by css id):
        Assertions.assertThat(robot.lookup("#myButton").queryAs(Button.class)).hasText("click me!");
        // or (lookup by css class):
        Assertions.assertThat(robot.lookup(".button").queryAs(Button.class)).hasText("click me!");
        // or (query specific type):
        Assertions.assertThat(robot.lookup(".button").queryButton()).hasText("click me!");
    }

    /**
     * @param robot - Will be injected by the test runner.
     */
    @Test
    void when_button_is_clicked_text_changes(FxRobot robot) {
        // when:
        robot.clickOn(".button");

        // then:
        Assertions.assertThat(button).hasText("clicked!");
        // or (lookup by css id):
        Assertions.assertThat(robot.lookup("#myButton").queryAs(Button.class)).hasText("clicked!");
        // or (lookup by css class):
        Assertions.assertThat(robot.lookup(".button").queryAs(Button.class)).hasText("clicked!");
        // or (query specific type)
        Assertions.assertThat(robot.lookup(".button").queryButton()).hasText("clicked!");
    }
}

Spock with Hamcrest Matchers

import org.testfx.framework.spock.ApplicationSpec;

class ClickableButtonSpec extends ApplicationSpec {
    @Override
    void init() throws Exception {
        FxToolkit.registerStage { new Stage() }
    }

    @Override
    void start(Stage stage) {
        Button button = new Button('click me!')
        button.setOnAction { button.setText('clicked!') }
        stage.setScene(new Scene(new StackPane(button), 100, 100))
        stage.show()
    }

    @Override
    void stop() throws Exception {
        FxToolkit.hideStage()
    }

    def "should contain button"() {
        expect:
        verifyThat('.button', hasText('click me!'))
    }

    def "should click on button"() {
        when:
        clickOn(".button")

        then:
        verifyThat('.button', hasText('clicked!'))
    }
}

Continuous Integration (CI)

Travis CI

To run TestFX tests as part of your Travis CI build on Ubuntu and/or macOS take the following steps:

Ensure that your unit tests are triggered as part of your build script. This is usually the default case when using Maven or Gradle.

If you wish to test in a headless environment your must add Monocle as a test dependency:

build.gradle

dependencies {
    testCompile "org.testfx:openjfx-monocle:8u76-b04" // jdk-9+181 for Java 9, jdk-11+26 for Java 11
}

pom.xml

<dependency>
    <groupId>org.testfx</groupId>
    <artifactId>openjfx-monocle</artifactId>
    <version>8u76-b04</version> <!-- jdk-9+181 for Java 9, jdk-11+26 for Java 11 -->
    <scope>test</scope>
</dependency>

Base your Travis configuration on the following. Some different build variations are shown (Glass/AWT robot, Headed/Headless, (Hi)DPI, etc.) adjust the build matrix to your requirements.

.travis.yml

language: java

sudo: false   # Linux OS: run in container

matrix:
  include:
    # Ubuntu Linux (trusty) / Oracle JDK 8 / Headed (AWT Robot)
    - os: linux
      dist: trusty
      jdk: oraclejdk8
      env:
        - _JAVA_OPTIONS="-Dtestfx.robot=awt"
    # Ubuntu Linux (trusty) / Oracle JDK 8 / Headed (Glass Robot) / HiDPI
    - os: linux
      dist: trusty
      jdk: oraclejdk8
      env:
        - _JAVA_OPTIONS="-Dtestfx.robot=glass -Dglass.gtk.uiScale=2.0"
    # Ubuntu Linux (trusty) / Oracle JDK 8 / Headless
    - os: linux
      dist: trusty
      jdk: oraclejdk8
      env:
        - _JAVA_OPTIONS="-Djava.awt.headless=true -Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw"
    # macOS / Oracle JDK 8 / Headless
    - os: osx
      osx_image: xcode9.4
      jdk: oraclejdk8
      env:
        - _JAVA_OPTIONS="-Djava.awt.headless=true -Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw -Dprism.verbose=true"
    # Headed macOS is not currently possible on Travis.

addons:
  apt:
    packages:
      - oracle-java8-installer

before_install:
  - if [[ "${TRAVIS_OS_NAME}" == linux ]]; then export DISPLAY=:99.0; sh -e /etc/init.d/xvfb start; fi

install: true

before_script:
  - if [[ "${TRAVIS_OS_NAME}" == osx ]]; then brew update; brew cask reinstall caskroom/versions/java8; fi

script:
  - ./gradlew check

before_cache:
  - rm -f  $HOME/.gradle/caches/modules-2/modules-2.lock
  - rm -fr $HOME/.gradle/caches/*/plugin-resolution/
  - rm -f  $HOME/.gradle/caches/*/fileHashes/fileHashes.bin
  - rm -f  $HOME/.gradle/caches/*/fileHashes/fileHashes.lock

cache:
  directories:
    - $HOME/.gradle/caches/
    - $HOME/.gradle/wrapper/
    - $HOME/.m2

Your TestFX tests should now run as part of your Travis CI build.

Appveyor (Windows)

To run TestFX tests as part of your Appveyor build on Windows take the following steps:

Ensure that your unit tests are triggered as part of your build script. This is usually the default case when using Maven or Gradle.

If you wish to test in a headless environment your must add Monocle as a test dependency:

build.gradle

dependencies {
    testCompile "org.testfx:openjfx-monocle:8u76-b04" // jdk-9+181 for Java 9
}

pom.xml

<dependency>
    <groupId>org.testfx</groupId>
    <artifactId>openjfx-monocle</artifactId>
    <version>8u76-b04</version> <!-- jdk-9+181 for Java 9 -->
    <scope>test</scope>
</dependency>

Base your Appveyor configuration on the following. Some different build variations are shown (Glass/AWT robot, Headed/Headless, (Hi)DPI, etc.) adjust the build matrix to your requirements.

appveyor.yml

version: "{branch} {build}"
environment:
  matrix:
    # Java 8 / AWT Robot
    - JAVA_VERSION: "8"
      JAVA_HOME: C:\Program Files\Java\jdk1.8.0
      _JAVA_OPTIONS: "-Dtestfx.robot=awt -Dtestfx.awt.scale=true"
    # Java 8 / AWT Robot / HiDPI
    - JAVA_VERSION: "8"
      JAVA_HOME: C:\Program Files\Java\jdk1.8.0
      _JAVA_OPTIONS: "-Dtestfx.robot=awt -Dtestfx.awt.scale=true -Dglass.win.uiScale=200%"
    # Java 8 / Headless
    - JAVA_VERSION: "8"
      JAVA_HOME: C:\Program Files\Java\jdk1.8.0
      _JAVA_OPTIONS: "-Djava.awt.headless=true -Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw -Dprism.text=t2k"
    # Java 10 / AWT Robot / HiDPI
    - JAVA_VERSION: "10"
      JAVA_HOME: C:\jdk10
      _JAVA_OPTIONS: "-Dtestfx.robot=awt -Dtestfx.awt.scale=true -Dglass.win.uiScale=200%"
    # Java 11 / AWT Robot / HiDPI
    - JAVA_VERSION: "11"
      JAVA_HOME: C:\jdk11
      _JAVA_OPTIONS: "-Dtestfx.robot=awt -Dtestfx.awt.scale=true -Dglass.win.uiScale=200%"

build_script:
  - ps: |
      if ($env:JAVA_VERSION -eq "11") {
        $client = New-Object net.webclient
        $client.DownloadFile('http://jdk.java.net/11/', 'C:\Users\appveyor\openjdk11.html')
        $openJdk11 = cat C:\Users\appveyor\openjdk11.html | where { $_ -match "href.*https://download.java.net.*jdk11.*windows-x64.*zip\`"" } | %{ $_ -replace "^.*https:", "https:" } | %{ $_ -replace ".zip\`".*$", ".zip" }
        echo "Download boot JDK from: $openJdk11"
        $client.DownloadFile($openJdk11, 'C:\Users\appveyor\openjdk11.zip')
        Expand-Archive -Path 'C:\Users\appveyor\openjdk11.zip' -DestinationPath 'C:\Users\appveyor\openjdk11'
        Copy-Item -Path 'C:\Users\appveyor\openjdk11\*\' -Destination 'C:\jdk11' -Recurse -Force
      }
      elseif ($env:JAVA_VERSION -eq "10") {
        choco install jdk10 --version 10.0.2 --force --cache 'C:\ProgramData\chocolatey\cache' -params 'installdir=c:\\jdk10'
      }

      // Note: Currently Java 8 is the default JDK, if that changes the above will have to change accordingly.

shallow_clone: true

build:
  verbosity: detailed

test_script:
  - gradlew build --no-daemon

cache:
  - C:\Users\appveyor\.gradle\caches
  - C:\Users\appveyor\.gradle\wrapper -> .gradle-wrapper\gradle-wrapper.properties
  - C:\ProgramData\chocolatey\bin -> appveyor.yml
  - C:\ProgramData\chocolatey\lib -> appveyor.yml
  - C:\ProgramData\chocolatey\cache -> appveyor.yml

Chat

Head over to our gitter chat for discussion and questions.

TestFX Legacy: Deprecated

The testfx-legacy subproject is deprecated and no longer supported. It is highly recommended that you switch from using testfx-legacy. If you want to continue using it you should cap the versions of testfx-core and testfx-legacy to 4.0.8-alpha, which was the last released version of testfx-legacy. Using a newer version of testfx-core with an older version of testfx-legacy will very likely break (and does with testfx-core versions past 4.0.10-alpha).

Credits

Thanks to all of the contributors of TestFX!

Comments

Question: What is bare minimum needed to build on Travis CI for Linux and OSX environments?

What is the bare minimum I need to do in order for TestFX to work in Travis CI builds if I'm building for both Linux and OSX environments?

I know a page about this already exists, but I wasn't sure how much of it still applies (there are some outdated pages in the wiki)? I've looked at TestFX's Travis-related files, and based mine off of them. However, I haven't been able to get mine to work. The Linux OS times out, and the OSX's JVM crashes. They are below: .travis.yaml

language: java

# enable Java 8u45+, see https://github.com/travis-ci/travis-ci/issues/4042
addons:
  apt:
    packages:
      - oracle-java8-installer

# run in container
sudo: false

matrix:
  fast_finish: true
  include:
    - os: linux
      dist: trusty
      jdk: oraclejdk8
    - os: osx
      osx_image: xcode8.2

before_install:
  - chmod +x .ci/before_install.sh
  - .ci/before_install.sh

script:
  - chmod +x .ci/script.sh
  - .ci/script.sh

before_install.sh

#!/usr/bin/env bash

# Taken from TestFX's .ci/before_install.sh
if [[ "${TRAVIS_OS_NAME}" == osx ]]; then
  brew update
  brew upgrade
  brew cask install java
  brew install gradle
  brew unlink python # fixes 'run_one_line' is not defined error in backtrace
else
  # Linux OS: use framebuffer for UI
  export DISPLAY=:99.0
  sh -e /etc/init.d/xvfb start
fi

script.sh

#!/usr/bin/env bash

# Taken from TestFX
ulimit -c unlimited -S

gradle assemble
gradle check

# Print core dumps when JVM crashes.
RESULT=$?
if [[ ${RESULT} -ne 0 ]]; then
  JVMCRASH="$(find . -name "hs_err_pid*.log" -type f -print | head -n 1)"
  if [ -f "$JVMCRASH" ]; then
    echo "======= JVM Crash Log $JVMCRASH ======="
    cat "$JVMCRASH"
  fi

  CORES=''
  if [[ "${TRAVIS_OS_NAME}" == osx ]]; then
    CORES="$(find /cores/ -type f -print)"
  else
    CORES="$(find . -type f -name 'core.*' -print)"
  fi

  if [ -n "${CORES}" ]; then
    for core in ${CORES}; do
    echo "======= Core file $core ======="
    if [[ "${TRAVIS_OS_NAME}" == osx ]]; then
      lldb -Q -o "bt all" -f "$(which java)" -c "${core}"
    else
      gdb -n -batch -ex "thread apply all bt" -ex "set pagination 0" "$(which java)" -c "${core}"
    fi
  done
  fi

  exit ${RESULT}
fi

opened by JordanMartinez 40

CDI integration

Previous discussion (from other issue):

@svenruppert:

Hi, as Henrik wrote.. I am working on an CDI bootstrap for TestFX. The first tests are good. So I would like to create three maven modules. The first one would be the parent with the dep management. the second the TestFX without CDI and the third one based on the second one with CDI support. For the combination I would use an aproch like I described in my blog: http://www.rapidpm.org/2014/01/fxcontroller-with-cdi-managed.html. Same for the CDI bootstrap. let me know if this would be ok for you all. If yes, I would create the three modules first, so that we can merge this soon to master branch.

@Philipp91:

@svenruppert Do you have something like a per-window Context/Scope for your CDI integration? I have my own CDI bootstrap for JavaFX. Integrating this with TestFX was as easy as replacing the internally used javafx.application.Application-implementation by my own one. That's why I asked about this feature above. Maybe you could use that, too? I don't understand what the second maven module (TestFX without CDI) is about. Wouldn't it be enough to have TestFX, CDI4FX (or whatever your CDI-JavaFX integration is called) - both of which already exist - and only one more module that contains a class like CDIGuiTest, which extends GuiTest?

@svenruppert:

@Philipp91 Well the CDI module would have more deps.. additional classes on cdi side and changes inside the non-CDI module, because I would bootstrap the tests itself too. But in a way you don´t need Arquillian. The FX stuff is mostly Java SE and if you don´t want to use CDI you don´t want to have this deps/classes inside your project. I would say, three modules would be the clean way to do it.. If possible I would like to see your CDI bootstrap, and I think to integrate a additionaly scope would be possible.

@hastebrot:

@svenruppert I really like your concept with the three maven modules.

@Philipp91:

Okay, so your TestFX integration allows to use injection inside the test classes? That sounds great. I currently have to use methods like "getBean(SomeClass.class)" etc. ...

You can see my implementation, it is currently integrated with a project and therefore in aprivate BitBucket repository. I can add you there or send you an email. However, I wouldn't consider it stable. It needs to intercept all (JavaFX) events, which does not work in all cases. Mostly PopupWindows (used by Menu, ChoiceBox, etc.) cause problems. It works fine for this specific application, but currently, we have to use special "AttachedMenuItem"s etc. instead of the normal JavaFX classes. Refer to https://community.oracle.com/thread/2592504 for details and to https://javafx-jira.kenai.com/browse/RT-33543 for a possible solution (scheduled for Java 9 ...). But maybe there is a different, better way to do this. The general problem that needs to be solved is that the same thread (JavaFX main UI thread) is responsible for all windows, so at some place someone needs to tell which window the thread is currently working on.

@svenruppert:

@Philipp91 Maybe I have a basic step for a solution.. ContextResolver are usefull in my projects .. but this for later.. And yes, you can use CDI inside the tests (and the TestFX Framework itself) too.. and no Arquillian needed.. The first tests are all green.

What are the final steps? First finishing the refactorings and tests.. After this creating the three modules ( I could do it if it is ok) After this I would branch again for the CDI support.

t:enhancement

opened by minisu 31

Test classes appear to affect each other

Create two test classes, A and B; ensure class A always runs first. Both of these test classes succeed when independently.

In class A, in BeforeClass register the primary stage, create a target stage. Then I setUp the stage, and then I wait for FX events. Like so:

    FxToolkit.registerPrimaryStage();
    fxRobot.target(FxToolkit.registerTargetStage(() -> {
                Stage stage = new Stage();
                stage.setTitle("Demo Stage");
                return stage;
            }
    ));
    FxToolkit.setupStage((stage) -> {
        stage.show();
        stage.toBack();
        stage.toFront();
    });
    WaitForAsyncUtils.waitForFxEvents();

Then I test the stage name and all is good.

In class B, in Before I register the primary stage, then I setUp the stage, then I setUp the scene root, then wait for FX events. getRootNode returns a simple anchorPane with a grid with a button and a comboBox.

    fxRobot.target(FxToolkit.registerPrimaryStage());   
    FxToolkit.toolkitContext().getTargetStage().getTitle());
    FxToolkit.setupStage((stage) -> {
        stage.show();
        stage.toBack();
        stage.toFront();
    });
    FxToolkit.setupSceneRoot(() -> {
                return getRootNode();
            }
    );
    WaitForAsyncUtils.waitForFxEvents();

Then my tests test the button and the combo box. They run into NPEs attempting to find the nodes:

java.lang.NullPointerException
at org.testfx.service.finder.impl.NodeFinderImpl.findNodesInParent(NodeFinderImpl.java:204)
at org.testfx.service.finder.impl.NodeFinderImpl.lambda$fromNodesCssSelectorFunction$28(NodeFinderImpl.java:191)
at org.testfx.service.finder.impl.NodeFinderImpl$$Lambda$182/1908923184.apply(Unknown Source)
at com.google.common.collect.Iterators$8.transform(Iterators.java:799)
at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at com.google.common.collect.Iterators$5.hasNext(Iterators.java:548)
at com.google.common.collect.Iterators$7.computeNext(Iterators.java:650)
at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at com.google.common.collect.ImmutableSet.copyOf(ImmutableSet.java:318)
at com.google.common.collect.ImmutableSet.copyOf(ImmutableSet.java:300)
at org.testfx.service.finder.impl.NodeFinderImpl.transformToResultNodes(NodeFinderImpl.java:178)
at org.testfx.service.finder.impl.NodeFinderImpl.nodesImpl(NodeFinderImpl.java:160)
at org.testfx.service.finder.impl.NodeFinderImpl.nodes(NodeFinderImpl.java:90)
at org.testfx.service.finder.impl.NodeFinderImpl.node(NodeFinderImpl.java:75)
at com.poorfellow.graphing.experimental.test.JavaFXViewsTest.testButtonClick(JavaFXViewsTest.java:67)

Here's where things get interesting: I tried to add an AfterClass method to class A that used WaitForAsyncUtils.asyncFx(() to find and close the stage I had set. This time when I ran the tests, class B hung on both setupStage() and setupSceneRoot(); I tried to alter the order.

It looks like some stale data is being left around in FxToolkit, but that's a wildly uninformed guess.

t:bug a:toolkit

opened by zerocool947 29

(refactor) Extract robot and service classes from GuiTest.
This is my work-in-progress which extracts robot and service classes from org.loadui.testfx.GuiTest. It is an experiment to see if a modular approach is better than the current monolithic approach.

Framework:

[x] Extract framework.FxRobotImpl that implements all robot interfaces (is-a KeyboardRobot, MouseRobot, ClickRobot, ...) and contains service classes (has-a NodeFinder, ScreenLocator, ScreenCapturer, ...).

[x] Rename to framework.ScreenRobotImpl from FxScreenController.

[x] Rename to framework.junit.StageRobotTest from GuiTest that inherits framework.FxRobot and implements service.SceneProvider.

[x] ~~Create framework.FxRobotConfig to configure timeouts and pauses.~~

Robots:

[x] Extract robot.KeyboardRobot with press and release methods.

[x] Extract robot.MouseRobot with press and release methods.

[x] Extract robot.ClickRobot with click, rightClick and doubleClick methods.

[x] Extract robot.DragRobot with drag, drop, dropTo and dropBy methods.

[x] Extract robot.MoveRobot with moveTo and moveBy methods.

[x] Extract robot.ScrollRobot with scroll, scrollUp and scrollDown methods.

[x] Extract robot.SleepRobot with sleep method.

[x] Extract robot.TypeRobot with type and erase methods.

Services:

[x] Extract service.stage.StageApplication with TestFxApp functionality.

[x] Extract service.stage.StageRetriever with setupStage and showNodeInStage methods.

[x] Extract service.stage.SceneProvider with getRootNode methods.

[x] Extract service.locator.PointLocator with pointFor and pointForBounds methods.

[x] Extract service.locator.BoundsLocator with sceneBoundsToScreenBounds method.

[x] Extract service.finder.NodeFinder with static find, findAll, findAllRecursively, exists, labelExists and selectorExists methods.

[x] Extract service.finder.WindowFinder with getWindows, getWindowByIndex and findStageByTitle methods.

[x] Extract service.capturer.ScreenCapturer with captureScreenshot method.

Miscellanous:

[x] Cleanup static waitUntil() functionality.

[x] Cleanup target(), and static targetWindow() and lastSeenWindow functionality.

[x] Cleanup pos() and nodePosition functionality.

[x] Replace static offset() and OffsetTarget functionality with PointQuery.
opened by hastebrot 24
[WIP] (refactor) Use Java-version-independent adapter for internal API
There's a number of issues with the current state of this PR only because I'm not yet familiar with how to set up some things with Java 9 or integrate it into this project's somewhat complex build system.

Tests don't work correctly due to not having access to things

Javadoc warns of bad javadoc (using & instead & and > instead of >)

CI files need to be updated

At least that was the issues it raised. I changed something in the build file and now it doesn't work due to

* What went wrong: Execution failed for task ':testfx-internal-java9:javadoc'. > Could not write to file 'TestFX/subprojects/testfx-internal-java9/build/tmp/javadoc/javadoc.options'.
opened by JordanMartinez 22
Add method verifyThat(Predicate), where R is the type of root node
It would be nice to have a verifyThat method that tests some property of the root node. To do that, I propose to parameterize the GuiTest class by the type of the root node, and add a verifyThat method that tests the root node:

class GuiTest<R extends Node> { protected abstract R getRootNode(); public final void verifyThat(Predicate<R> test); }
opened by TomasMikula 21
JUnit5 TestFX extension to execute @Test within JavaFX UI thread

Simple JUnit 5 extension to ensure that @test statements are executed in the JavaFX UI thread. This is (strictly) necessary when testing setter and/or getter methods of JavaFX classes (ie. Node derived, properties, etc).

See also issue #700 and real-world usage in the following example project

Tests compile successfully with Maven but I am unfamiliar with Gradle and TestFX's use of it. Presently org.junit.platform.commons.logging.Logger[Factory] module/visibility isn't properly exported.

@brcolow -- since you kindly suggested this PR -- could you have a look/fix this Gradle issue?

Many thanks in advance. Much appreciated :+1: Hope this is useful also for others.

opened by RalphSteinhagen 19
TestFX 4.0.7-alpha introduced larger memory use

Starting with release 4.0.7-alpha, running TestFX with monocle uses more memory than before and has started causing OutOfMemoryErrors. Increasing the max JVM memory has mitigated the issue but over 1G of memory was used on fewer than 20 tests. This has been hard to track down because support for Java 9 was also introduced in this time period. Testing was done using Oracle Java 1.8.0_144 on Ubuntu Server 17.04. The higher memory use continues in TestFX 4.0.8-alpha.

opened by mvsoder 18
Proposed fix for 274: Failing tests in AWTRobotAdapterTest and GlassRobotAdapterTest
Issue

See #274

Solution

Added waitForFxEvents(); in FXToolKit's waitForSetup Method. This should ensure, that all events are processed prior to any tests. The downside is, that tests take a little bit longer (assumed 30-50ms per test).

Not solved

Implemented tests --> tests were failing before on my system

Can anybody (with a similar platform as the build server) implement a testcase with the current master branch, that also fails on the build server because of this condition?
opened by Ortner 18
Support of foreign keyboards

By modifiying the TypeRobot, I propose to create keycharmap files to map wanted characters to combination of key codes.

The first file is my own keyboard, which is French Azerty keyboard.

Please read the README.md file into the src/main/resources/keycharmaps folder.
t:bug t:enhancement a:robot s:needs-test

opened by lgringo 18
TestFX crashes test thread

When I run the basic test example, the test thread crashes.

The error differs from how I run the test. command line mvn test on the module:

[xcb] Unknown request in queue while dequeuing [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. java: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed. Aborted (core dumped)

In NetBeans right click test on the test class:

*** glibc detected *** /usr/lib/jvm/java-7-oracle/jre/bin/java: free(): invalid next size (normal): 0x00007f5e78041b70 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f5ed6f9ab96] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x37313)[0x7f5eb7451313] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x375eb)[0x7f5eb74515eb] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x3798a)[0x7f5eb745198a] /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x64fd6)[0x7f5ebd38efd6] /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(gdk_x11_get_xatom_by_name_for_display+0x75)[0x7f5ebd38f485] /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5923f)[0x7f5ebd38323f] /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(gdk_x11_screen_supports_net_wm_hint+0x9e)[0x7f5ebd38628e] /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(gdk_window_focus+0x100)[0x7f5ebd3976c0] /usr/lib/jvm/java-7-oracle/jre/lib/amd64/libglass.so(Java_com_sun_glass_ui_gtk_GtkWindow__1requestFocus+0xd)[0x7f5ec41f0a8d] [0x7f5ecd012738]

JDK: java version "1.7.0_40" Java(TM) SE Runtime Environment (build 1.7.0_40-b43) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

Maven: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /usr/share/maven3 Java version: 1.7.0_40, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-oracle/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.2.0-49-generic", arch: "amd64", family: "unix"

opened by monezz 18
Double click to slow in FxRobot.doubleClickOn()
Expected Behavior

A double click should be simulated on a cell of a table view. MouseEvent.getClickCount() should return 2.

Actual Behavior

The click is performed, but the MouseEvent.getClickCount() always returns 1. The double click is interpreted as two single clicks.

Specifications

Version: 4.0.16-alpha

Platform: Windows 10
opened by ADieGefa 0
Does TestFX support JavaFX 17 and JDK 17 yet?
Expected Behavior

Actual Behavior

To get the fastest possible support, create a minimal example and upload it to GitHub.

Specifications

Version:

Platform:
opened by yylonly 4
Headless testing Java 11 AbstractMethodError
Expected Behavior

Should be able to run TestFX in Headless mode.

Actual Behavior

TestFX in headless mode produces the following error:

java.lang.AbstractMethodError: Receiver class com.sun.glass.ui.monocle.MonocleTimer does not define or inherit an implementation of the resolved method abstract _pause(J)V of abstract class com.sun.glass.ui.Timer. at com.sun.glass.ui.Timer.pause(Timer.java:143) at com.sun.javafx.tk.quantum.QuantumToolkit.pauseTimer(QuantumToolkit.java:514) at com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:501) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$12(QuantumToolkit.java:355) at com.sun.glass.ui.monocle.MonocleTimer$1.run(MonocleTimer.java:58) at java.base/java.util.TimerThread.mainLoop(Timer.java:556) at java.base/java.util.TimerThread.run(Timer.java:506)

Specifications

Java Version: 11

Platform: Windows 10

JavaFx Version: 18.0.1

TestFx Version: 4.0.16-alpha

Few system properties are set in each test class as below:

System.setProperty("testfx.robot", "glass"); System.setProperty("testfx.headless", "true"); System.setProperty("prism.order", "sw"); System.setProperty("prism.text", "t2k"); System.setProperty("java.awt.headless", "true");
opened by rajashreesidhanti 0
Module Error: Test Package is not Exported to org.testfx.junit5
Expected Behavior

After using @ExtendWith(ApplicationExtension.class) and defining a @Start method, I would expect that unit tests would run properly in that class.

Actual Behavior

When attempting to run a unit test , I get an error message for the @Start class.

Unable to make public void com.candle.fileexplorertest.view.DirectoryButtonControllerTests.start(javafx.stage.Stage) accessible: module FileExplorer does not "exports com.candle.fileexplorertest.view" to module org.testfx.junit5.

The issue here is that I don't see how I can export test code to org.testfx.junit5 . My module-info.java file is located inside src/main/java , and therefore has no way of accessing a unit test package in src/test/java . I tried creating a second module-info.java for the test code so I could export the , but that brought its own issues and did not seem to resolve the problem

I have only experienced this issue with a modular JavaFX project. If I delete the module-info.java file, then the test runs fine.

The Unit Test Class That I'm Having an Issue With

Admittedly, this project includes additional classes that are not provided here. However, the problem I'm experiencing seems to only involve the unit test code.

package com.candle.fileexplorertest.view; (imports here) @ExtendWith(ApplicationExtension.class) public class DirectoryButtonControllerTests { DirectoryButtonController testButton; DirectoryButtonViewModel viewModel; Image image; @Start public void start(Stage stage) { viewModel = mock(DirectoryButtonViewModel.class); image = new Image("/com/candle/fileexplorer/images/16/Folder.png"); testButton = new DirectoryButtonController(viewModel, image); Parent sceneRoot = new StackPane(testButton); Scene scene = new Scene(sceneRoot); stage.setScene(scene); stage.show(); stage.toFront(); } @Test public void goToDirectory_shouldTellViewModel_whenButtonClicked(FxRobot robot) { robot.clickOn(testButton); verify(viewModel).goToDirectory(); } }

Module-Info.java

module FileExplorer { requires javafx.controls; requires javafx.fxml; requires javafx.graphics; exports com.candle.fileexplorer; opens com.candle.fileexplorer to javafx.graphics; opens com.candle.fileexplorer.view to javafx.fxml; }

Specifications

Version: TestFX 3.1.2

Platform: Linux
opened by cachandlerdev 0

Internal graphics not initialized yet

The following test fails about once every 10 runs with Internal graphics not initialized yet (i.e. the test works 90% of the time) :

package se.alipsa.rideutils;

import javafx.application.Platform;
import javafx.scene.image.Image;
import javafx.stage.Stage;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;;
import org.testfx.api.FxRobot;
import org.testfx.framework.junit5.ApplicationExtension;
import org.testfx.framework.junit5.Start;

import java.io.IOException;

import static org.junit.jupiter.api.Assertions.assertNotNull;

@ExtendWith(ApplicationExtension.class)
public class ReadImageTest  {

  @Start
  public void start(Stage stage) {
    stage.show();
  }

  @Test
  public void testReadSvg() throws IOException {
    Image img = ReadImage.read("sinplot.svg");
    assertNotNull(img);
  }

  @Test
  public void testReadPng() throws IOException {
    Image img = ReadImage.read("plot.png");
    assertNotNull(img);
  }

  @Test
  public void testReadJpg() throws IOException {
    Image img = ReadImage.read("dino.jpg");
    assertNotNull(img);
  }
}

the stack trace produced when it fails is:

Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.773 sec <<< FAILURE!
se.alipsa.rideutils.ReadImageTest.testReadJpg()  Time elapsed: 0.286 sec  <<< FAILURE!
java.lang.RuntimeException: Internal graphics not initialized yet
        at javafx.graphics/com.sun.glass.ui.Screen.getScreens(Screen.java:70)
        at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.getScreens(QuantumToolkit.java:710)
        at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.getMaxRenderScale(QuantumToolkit.java:737)
        at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(QuantumToolkit.java:746)
        at javafx.graphics/javafx.scene.image.Image.loadImage(Image.java:1052)
        at javafx.graphics/javafx.scene.image.Image.initialize(Image.java:802)
        at javafx.graphics/javafx.scene.image.Image.<init>(Image.java:618)
        at se.alipsa.rideutils.ReadImage.read(ReadImage.java:42)
        at se.alipsa.rideutils.ReadImageTest.testReadJpg(ReadImageTest.java:38)

I am using openjdk version "11.0.14" 2022-01-18 LTS OpenJDK Runtime Environment (build 11.0.14+9-LTS) OpenJDK 64-Bit Server VM (build 11.0.14+9-LTS, mixed mode)

with the following dependencies

    <dependency>
      <groupId>org.openjfx</groupId>
      <artifactId>javafx-controls</artifactId>
      <version>17.0.2</version>
    </dependency>

    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter-api</artifactId>
      <version>5.8.2</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.testfx</groupId>
      <artifactId>testfx-junit5</artifactId>
      <version>4.0.16-alpha</version>
      <scope>test</scope>
    </dependency>

Is there something I can do prevent tests from running before the environment has finished initializing?

opened by perNyfelt 0

Releases(v4.0.4-alpha)

v4.0.4-alpha(Mar 30, 2016)
6 commits by 1 author:

Benjamin Gudehus (@hastebrot) — 6 commits

2 merged pull requests:

(feat) Introduce FxRobot::bounds() and BoundsQuery. (#258) — 3 commits

(refactor) ApplicationService: Use Application instead of ApplicationFixture. (#257) — 3 commits

Source code(tar.gz)
Source code(zip)
v4.0.3-alpha(Mar 25, 2016)
23 commits by 2 authors:

Benjamin Gudehus (@hastebrot) — 16 commits

Michael Ennen (@brcolow) — 7 commits

6 merged pull requests:

(feat) Add PixelMatcher to CaptureSupport. (#248) — 15 commits

(feat) ListViewMatchers: Add hasPlaceholder(Node placeholder). (#252) — 1 commit

(feat) ListViewMatchers: Add isEmpty(). (#251) — 2 commits

(feat) TableViewMatchers: Add containsRow(). (#255) — 1 commit

(feat) TextFlowMatchers: Add matchers for the text of a TextFlow. (#259) — 3 commits

(refactor) NodeQuery: Rename methods to match(), nth() and query(). (#250) — 1 commit

Source code(tar.gz)
Source code(zip)
v4.0.2-alpha(Feb 22, 2016)
18 commits by 4 authors:

Benjamin Gudehus (@hastebrot) — 14 commits

John Zeringue (@johnzeringue) — 3 commits

Joachim Prinzbach (@joachimprinzbach) — 1 commit

9 merged pull requests:

(chore) Travis: Allow jobs without framebuffer to fail. (#211) — 1 commit

(chore) Travis: Run tests once with and once without framebuffer screen. (#209) — 6 commits

(feat) Add FxRobot::interrupt() method to wait for the JavaFX thread. (#240) — 1 commit

(feat) hasTableCell(): Match the string value of cell item. (#210) — 1 commit

(feature) Added ApplicationRule (#234) — 1 commit

(fix) WriteRobot::write() to prefer the Scene of the focused window. (#239) — 1 commit

(refactor) Improve encapsulation of classes. (#233) — 1 commit

(refactor) Rename window methods to targetWindow(), listWindows(), and window(). (#238) — 1 commit

Fixed google group link (#221) — 1 commit

Source code(tar.gz)
Source code(zip)
v4.0.1-alpha(Mar 4, 2015)
23 commits by 1 author:

Benjamin Gudehus (@hastebrot) — 23 commits

3 merged pull requests:

(feat) JUnit: Add support classes, including an ApplicationTest base test class. (#163) — 8 commits

(refactor) Service: Make NodeFinder more familiar to JavaFX developers. (#205) — 2 commits

(revert) Legacy: Revert GuiTest and remove ApplicationTest, FxTest and CustomAppTest. (#204) — 1 commit

Source code(tar.gz)
Source code(zip)
testfx-core-4.0.1-alpha-javadoc.jar(543.42 KB)
testfx-core-4.0.1-alpha-sources.jar(92.28 KB)
testfx-core-4.0.1-alpha.jar(108.52 KB)
testfx-junit-4.0.1-alpha-javadoc.jar(32.55 KB)
testfx-junit-4.0.1-alpha-sources.jar(1.81 KB)
testfx-junit-4.0.1-alpha.jar(2.05 KB)
testfx-legacy-4.0.1-alpha-javadoc.jar(151.67 KB)
testfx-legacy-4.0.1-alpha-sources.jar(21.57 KB)
testfx-legacy-4.0.1-alpha.jar(28.10 KB)
v4.0.0-alpha(Feb 27, 2015)
322 commits by 13 authors:

Benjamin Gudehus (@hastebrot) — 277 commits

Henrik Olsson — 11 commits

Sven Ruppert (@svenruppert) — 10 commits

Andres Almiray (@aalmiray) — 6 commits

Jan Gassen (@0x4a616e), Naimdjon Takhirov (@naimdjon) — 4 commits

Diego Cirujano (@Curuman) — 3 commits

Grégory Fernandez (@lgringo) — 2 commits

Andrea Vacondio (@torakiki), Johannes Mockenhaupt (@jotomo), Making GitHub Delicious. (@waffle-iron), Robert Ladstätter (@rladstaetter), Sergei Ivanov (@sergei-ivanov) — 1 commit

65 merged pull requests:

(chore) Gradle: Add project.jfxrtLocation to test.classpath. (#120) — 2 commits

(chore) Gradle: Build now runs with gradle clean jar javadocJar sourceJar test check. (#88) — 1 commit

(chore) Gradle: Cleanup build scripts. (#201) — 13 commits

(chore) Gradle: Fix missing Gradle wrapper. (#117) — 2 commits

(chore) Gradle: Reintroduce BinTray support. (#128) — 1 commit

(chore) Gradle: Remove JUnit compile dependency and update Guava. (#197) — 3 commits

(chore) Gradle: Rerun gradle wrapper. (#116) — 1 commit

(chore) Gradle: Temporarily remove BinTray support to fix Gradle view refresh in IntelliJ IDEA. (#127) — 1 commit

(chore) Travis: Add .travis.yml. (#118) — 1 commit

(chore) Travis: Try to use xvfb (X Virtual Framebuffer). (#119) — 1 commit

(doc) Add Unstable annotations to classes and methods. (#203) — 1 commit

(doc) Readme: Fix broken links to source code and update links to TestFX... (#142) — 1 commit

(doc) Readme: Update README.md. (#196) — 2 commits

(doc) Toolkit: Prepare docs and tests for candidate phase. (#176) — 12 commits

(feat) Allow instrumenting entire Applications. (#183) — 4 commits

(feat) Assert, Matcher: Implement type-aware matchers. (#164) — 16 commits

(feat) Assert, Matcher: Improve type-aware matchers. (#195) — 11 commits

(feat) Implement CallableBoundsPointQuery. (#68) — 5 commits

(feat) Lifecycle, Robot: Headless support. (#159) — 27 commits

(feat) Lifecycle: Implement LifecycleService. (#156) — 12 commits

(feat) ListViews provides a row selected matcher. (#202) — 3 commits

(feat) Robot: Add regression tests and create ClickRobotImpl. (#97) — 1 commit

(feat) Robot: Add regression tests and create DragRobotImpl. (#98) — 1 commit

(feat) Robot: Add regression tests and create MoveRobotImpl. (#96) — 1 commit

(feat) Robot: Implement adapters for Awt, Glass and JavaFX robots. (#146) — 7 commits

(feat) Robot: Support for Unicode strings in WriteRobot. (#166) — 6 commits

(feat) Service: Implement NodeQuery. (#174) — 7 commits

(feat) Util: Provide invokeIn...() and waitFor...() methods. (#150) — 1 commit

(fix) Add license header to MoveRobotImpl. (#112) — 1 commit

(fix) AppLauncher could not retrieve primary Stage on OSX. (#126) — 1 commit

(fix) Compiler warnings for deprecated JUnit methods. (#104) — 1 commit

(fix) Deprecation and compile warnings caused by dependency upgrades. (#198) — 4 commits

(fix) Matcher: nodeHasLabel() does not perform instance check for Text. (#124) — 1 commit

(fix) Service: Calls to Point2D#add() incompatible with Java 7. (#87) — 1 commit

(fix) Service: Fix compatibility to Java 7 and JavaFX 2. (#103) — 1 commit

(fix) Util: Only start waiting for boolean observable when it is false. (#151) — 2 commits

(refactor) API: Introduce FxSelector and FxSelectorContext. (#165) — 2 commits

(refactor) API: Move FxRobot to org.testfx.api. (#171) — 5 commits

(refactor) API: Move some org.loadui.testfx classes to org.testfx. (#172) — 9 commits

(refactor) API: Rename pointFor() to point() and add pointOfVisibleNode(). (#194) — 2 commits

(refactor) Extract robot and service classes from GuiTest. (#39) — 66 commits

(refactor) Framework: Extract ToolkitApplication. (#153) — 1 commit

(refactor) Legacy: Move org.loadui.testfx to testfx-legacy module. (#192) — 2 commits

(refactor) Robot: Add regression tests and refactor KeyboardRobotImpl. (#101) — 1 commit

(refactor) Robot: Add regression tests and refactor MouseRobotImpl. (#94) — 1 commit

(refactor) Robot: Add regression tests and refactor ScrollRobotImpl. (#100) — 1 commit

(refactor) Robot: Extract mouse methods to MouseRobotImpl and rename ... (#149) — 1 commit

(refactor) Robot: Refactor FxRobot. (#105) — 1 commit

(refactor) Robot: Refactor TypeRobotImpl. (#102) — 1 commit

(refactor) Robot: Revise Robots related to keyboard inputs. (#147) — 10 commits

(refactor) Toolkit: Prepare API for beta phase. (#170) — 6 commits

(refactor) Util: Enhance RunWaitUtils. (#154) — 4 commits

(test) Move ScrollPaneTest from unit tests to integration tests. (#99) — 1 commit

#110: jcenter is not supported in gradle < 1.7 (#113) — 3 commits

Extract static methods from FxRobot to GuiTest (#91) — 3 commits

Fix NP in containsCell in TableViews (#67) — 1 commit

Fix scroll direction as UP was going down (and DOWN up). (#95) — 2 commits

Misc fixes + bumped version. (#61) — 5 commits

No longer fixed scene size. (#62) — 1 commit

Respect headless mode instead of enforcing it (#137) — 1 commit

Setup a multi-project Gradle build (#71) — 4 commits

Update HasLabelStringMatcher.java (#108) — 1 commit

Update build files (#122) — 2 commits

make timeout configurable (#133) — 1 commit

waffle.io Badge (#134) — 1 commit

Source code(tar.gz)
Source code(zip)
testfx-core-4.0.0-alpha-javadoc.jar(535.20 KB)
testfx-core-4.0.0-alpha-sources.jar(90.46 KB)
testfx-core-4.0.0-alpha.jar(106.86 KB)
testfx-legacy-4.0.0-alpha-javadoc.jar(163.50 KB)
testfx-legacy-4.0.0-alpha-sources.jar(23.23 KB)
testfx-legacy-4.0.0-alpha.jar(29.97 KB)
v3.1.2(Jul 17, 2014)
Notice: It is recommended to use release v3.1.0, since v3.1.2 has some issues with ThreadDeath exception.

Now releases SHIFT, CTRL, ALT keys and mouse buttons on test fail.

User can now abort test by moving the mouse cursor manually.

No longer fixed scene size (you can test large nodes).

Improved error message for hasText matcher.

Now times out if the FX thread is not responding in 5 seconds.

Improved node searching.

Added pushNoWait and releaseNoWait.

Fixed TextInputControl.clear implementation. No runs in FX thread.

Source code(tar.gz)
Source code(zip)
v3.1.0(Jul 17, 2014)
New functionality:

Support for following labelFor references, using Commons.nodeLabeledBy.

#31: Support for clearing TextFields and TextAreas.

Fixes:

#33: Fixed odd drag-n-drop bug.

#36: Double clicking with secondary mouse button now works.

#37: Fixed generics (fewer warnings in code using TestFX).

Source code(tar.gz)
Source code(zip)
v3.0.0(Feb 26, 2015)
JavaFX 8 support.

Never clicks invisible nodes.

Never clicks nodes outside of scene.

Can now click nodes that are mostly outside of a scene.

TableView support.

ListView support.

No need to fork JVM between tests (no custom POM needed).

API change. Now implement getRootNode() instead of calling showNodeInStage().

Package restructuring.

Source code(tar.gz)
Source code(zip)