Suche
Der neue Stern am Testing-Himmel?

FX-Test: JUnit-Tests für JavaFX- und OSGi-Anwendungen

Dominik Mohilo

© Shutterstock.com / PowerUp

Not macht erfinderisch: Weil die Lizenz des JUnit-Test-Frameworks TestFX nicht mit den Bestimmungen der Eclipse Foundation konform ging, haben sich einige Entwickler von BestSolution eine Lösung für das Problem ausgedacht. Das Ergebnis ist ein neues Framework für JUnit-Tests von JavaFX-Anwendungen, das den Namen FX-Test trägt, und sich trotz aller Gemeinsamkeiten doch vom Vorreiter unterscheidet.

Das Framework TestFX hilft Entwicklern dabei, schnell und unkompliziert JUnit-Tests für JavaFX-Elemente zu schreiben. Das Framework hat mittlerweile ein paar Jahre auf dem Buckel und hat sich prächtig entwickelt. So weit, dass es von vielen Entwicklern als Quasi-Standard für das Schreiben von JUnit-Tests für JavaFX-Anwendungen angesehen wird.

Das galt bislang auch für Tom Schindl und sein Unternehmen BestSolution, die TestFX laut eigener Aussage sämtlichen Kunden und Projekten empfohlen hatten. Nun allerdings schicken sie mit dem selbstentwickelten Framework FX-Test den vermutlich schärfsten Konkurrenten für TestFX ins Rennen um die Gunst der Nutzer.

TestFX vs. FX-Test – die Unterschiede

Schon allein der Name verrät schnell, dass der Anspruch von FX-Test nicht die Neuerfindung des Rades war. Wie Tom Schindl auf seinem Blog schreibt, ging es wohl in erster Linie um unüberwindbare Lizenzprobleme. TestFX wurde seinerzeit unter der EUPL veröffentlicht, was zwar aus Entwicklersicht völlig in Ordnung sei, aber offenbar zu Problemen mit der Abteilung für geistiges Eigentum bei der Eclipse Foundation führte.

Ein weiterer Knackpunkt, der von FX-Test behoben werden soll, ist die Implementierung von JUnit-Tests für OSGi-JavaFX-Anwendungen. Das Problem von TestFX ist nämlich, dass dessen Bootstrap-Prozess nicht mit e4-OSGi-Anwendungen kompatibel ist. Das Schreiben von JUnit-Test wird in FX-Test durch das Subclassing von Grundklassen durchgeführt, bislang ist allerdings lediglich FXComponentTest verfügbar. So in etwa sieht eine typische Implementierung eines JUnit-Tests aus:

@Test
public void sample() {
  // Search with a css-selector query
  // and generated a click on the button
  rcontroller().cssFirst(".button").get().click();
}

FX-Test unterscheidet sich auch insofern, dass Tests nicht direkt ausgeführt werden können. Der Nutzer muss sich zuerst entscheiden, ob er einen spezifischen Runner nutzen will (über @RunWith(FXRunner.class) oder er eine Regel (@FXTest) nutzen und sämtliche UI-Test-Methoden damit annotieren möchte. Der Vorteil liegt darin, dass die @Test-Methoden im JavaFX-UI-Thread ausgeführt werden, nicht wie bei TestFX auf einem anderen Thread (etwa dem Main-Thread).

Tom Schindl ist vielen unserer Leser als Leiter des Projektes e(fx)clipse bekannt, dem JavaFX-Tooling und der JavaFX-Runtime für Eclipse und OSGi. Trotz des offensichtlichen Zusammenhanges haben sich die Mitarbeiter des FX-Test-Projektes zunächst dagegen entschieden, das Framework in e(fx)clipse fest zu integrieren. Stattdessen steht es als eigenständiges Projekt auf GitHub unter der Eclipse Public Licence (EPL) zur Verfügung.

Lesen Sie auch: TestFX: JUnit-Tests für JavaFX

Weitere Informationen zum neuen Framework FX-Test gibt es im Blog-Beitrag von Tom Schindl und wie oben erwähnt auf GitHub. Der Konkurrent, TestFX, ist ebenfalls auf GitHub verfügbar – und mit Version 4 (derzeit Alpha-Phase) steht ein neues Major Release bereits in den Startlöchern.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.