UISpec4J

Untersuchte Version

1.5 auf Eclipse 3.3.2 mit Java 1.5.0 und JUnit 3.8.1

Letzter Untersuchungszeitpunkt

29.10.2010

UISpec4J beansprucht für sich ein einfacher, leicht zu erlernender GUI-Tester zu sein, der aufgrund der Tatsache, dass er komplett auf JUnit aufsetzt, sich auch in umfangreichen Projekten mit komplexen Testszenarien bewährt.

Fazit

UISpec4J wird dem oben genannten Ziel nicht gerecht. Selbst wenn man die Betaversion für Java 6 außen vor lässt, bleibt bei vielen Dingen ein unausgegorener Nachgeschmack. So ist es kaum praktikabel, zum Vergleichen von GUI-Elementen für jedes Element einen Wrapper zu schreiben und daraus anschließend ein neues Jar-File zu erstellen, welches dem Projekt hinzugefügt werden muss. Zugegebenermaßen ist es ungeahnt einfach, einen Test zu schreiben der mit unterschiedlich beschrifteten Elementen interagiert und die Veränderung dieser Elemente kontrolliert. Sobald aber zwei GUI-Elemente den gleichen Text enthalten, kann UISpec4J sie nicht mehr unterscheiden und bricht mit einer Exception ab. Hier kommen wieder die Wrapper ins Spiel, die das Vergleichen erlauben. Dabei wird der Zeitvorteil, der durch die ansonsten kurzen und unkomplizierten Methodenaufrufe herausgearbeitet wurde, bei weitem wieder wettgemacht. Auch der Bug, der eine Benutzung unter Linux erschwert bis unmöglich macht, ist für einen Einsatz im professionellen Umfeld eigentlich ein K.O.-Kriterium. Eine uneingeschränkte Eignung kann UISpec4J eigentlich nur für Kleinstprojekte, bei denen während der Entwicklung schon auf die Bedürfnisse von UISpec4J eingegangen wird, ausgesprochen werden. Größere Projekte oder solche, die unter Linux entwickelt werden, sollten von UISpec4J Abstand nehmen.

Einsatzgebiete

Einfache GUI-Tests mit Unterstützung von JUnit entwickeln und über JUnit ausführen lassen.

Einsatzumgebungen

UISpec4J setzt ein vorhandenes JUnit voraus und muss aus JUnit TestCases heraus ausgeführt werden. Die verwendete Entwicklungsumgebung ist unerheblich, da UISpec4J nicht die Möglichkeit bietet, sich in eine IDE zu integrieren.

Installation

Die Installation ist scheinbar denkbar einfach. Es muss nur die Jar-Datei heruntergeladen und eingebunden werden. Voraussetzung, damit UISpec4J läuft ist ein ebenfalls eingebundenes JUnit. Seitens Java wird mindestens 1.4.2 aber höchstens 1.5.0 erwartet. Die aktuelle Java 6-Version wird noch nicht unterstützt. Danach kann man mit dem Schreiben von JUnit-Tests beginnen. Diese werden durch das Arsenal von GUI-Tests aus UISpec4J sinnvoll ergänzt. Dabei stellte sich jedoch sehr schnell heraus, dass ein "Init", das aufgerufen werden muss, um tiefergreifende Tests an der GUI vorzunehmen (z. B. PopUp-Windows einzufangen), unter Linux nicht unbedingt lauffähig ist. Der Mailinglist zufolge tritt dieser Bug ausschließlich unter Linux auf und kann gelegentlich mit einem dort beschriebenen Work-Around umgangen werden, der aber wiederum andere Tests unmöglich macht. Auf dem Testsystem war es auch nach mehreren Versuchen nicht möglich, den "Init" laufenzulassen.
Es existiert auch eine Betaversion für Java 6, deren Entwicklung aber scheinbar in einer sehr frühen Version abgebrochen wurde. Diese Version ist im Moment nicht lauffähig, da sie ihre eigenen Pakete nicht finden kann und Tests, die darauf referenzieren, sich nicht kompilieren lassen.

Dokumentation

Die Dokumentation setzt sich aus mehreren Beispielen auf der Projektseite sowie einer aus JavaDoc generierten Webseite zusammen. Grundsätzlich ist die Dokumentation knapp bis nicht vorhanden.
Die Beispiele zeigen anschaulich die Verwendung bestimmter Funktionen. Dabei wird allerdings nicht auf Probleme bei deren Verwendung eingegangen. Hier fällt auf, dass in den Beispielen nur die Funktionen gezeigt werden, die in UISpec4J besonders einfach und elegant gelöst wurden. Funktionen die weniger schön gelöst sind, werden entweder nicht beschrieben oder nur am Rand angesprochen.
Das Generieren der JavaDoc-Seite hätte man sich sparen können. Die meisten Methodenaufrufe sind gänzlich unkommentiert. So bleibt einem teilweise nur das Raten, welche Parameter die Methode denn erwartet und unter welchen Umständen was zurückgegeben wird. Es bleibt zu hoffen, dass sich das Entwicklerteam noch nicht aus dem Projekt zurückgezogen hat und hier noch nachbessert.

Wartung der Projektseite

Die Projektseite ist von Dezember 2007, seitdem wurde daran nichts mehr geändert. Die letzten Releases sind noch älteren Datums. Man beschränkt sich im Moment darauf, Nutzern in der Mailinglist zu helfen.

Nutzergruppen und Support

Auf der Projektseite finden sich eine Kontakt-Emailadresse, eine Mailinglist sowie ein Bugtracker. Der Bugtracker verrät viel über den Projektfortschritt: Seit Sommer 2007 fand hier keine Veränderung statt. Die Mailinglist wird sehr aktiv genutzt, aber auch wenn sich die Entwickler aktiv um die Probleme der User bemühen und die Fragen beantworten sowie bei Nutzerfehlern Hilfestellung geben, finden sich hier Bugs die seit 2006 bekannt sind aber immer noch nicht behoben wurden.

Intuitive Nutzbarkeit

Die grundlegenden Funktionen erschließen sich nach Lesen des Beispiels sehr schnell. Man ist beim Ausprobieren innerhalb kürzester Zeit in der Lage, die Beispiele zu reproduzieren. Doch dieses anfängliche Hoch ebbt schnell ab, wenn man von einfachem Buttonklicken den Wechsel zu einem ersten echten Test versucht. Viele dringend benötigte Funktionen existieren zwar, heißen aber anders als man erwartet und sind in keinster Weise dokumentiert. Bis man sich hier wirklich eingearbeitet hat, vergehen Stunden.

Automatisierung

Da UISpec4J eng mit JUnit verzahnt ist und vielfach von JUnit-Klassen erbt, müssten die Tests in JUnit-TestCases geschrieben werden. Dadurch sind sämtliche Automatisierungsmöglichkeiten von JUnit verfügbar.

ANT

Die Automatisierung des UISpec4J Frameworks mit Hilfe von ANT ist über die JUnit-Tasks Ausführung möglich. Dazu werden JUnit-Testklassen angelegt, die mit Hilfe des UISpec4J-Frameworks die Oberflächen-Tests durchführt. In Ant kann somit einfach auf die JUnit-Tasks zurückgegriffen werden, um die UISpec4J-Tests durchzuführen. Durch die Verwendung der JUnit-Tasks kann auf deren Funktionalitäten zurückgegriffen werden, wie z.B. die Erzeugung von XML-Reports und ähnlichen. Als Beispielautomatisierung wurde das bestehende TestGui-Projekt mit Ant automatisiert. Die Beispielautomatisierung ist hier zu finden.

Maven

Automatisierung Die Automatisierung der Testfälle ähnelt stark der Ausführung von JUnit-Testfällen. Der UISpec4J-Testfall wird in diesem Szenario durch einen JUnit-Testfall angestoßen und ist somit für den Maven-Prozess nicht direkt relevant. Die Sourcen müssen zwar beim Kompilieren und bei der Ausführung auf die UISpec4J-Bibliothek zugreifen, dies ist allerdings leicht mit Hilfe des <dependency>-Elements realisiert. Davor muss die UISpec4J-Bibliothek noch in das lokale Repository von Maven übertragen werden. Der folgende Befehl erledigt diesen Aspekt:

mvn install:install-file -DgroupId=uispec4j -DartifactId=uispec4j -Dversion=2.3 -Dfile=uispec4j.jar -Dpackaging=jar -DgeneratePom=true

Hierbei muss sich im aktuellen Ordner die uispec4j.jar befinden und die Version ist an die aktuelle anzupassen.
Die Ausführung des Tests ähnelt somit stark der Ausführung eines normalen JUnit-Testfalls. Durch den Aufruf mvn test wird der Testfall angestoßen und ausgeführt. Die Ergebnisse lassen sich dann im Target-Verzeichnis finden.
Ein einfaches Automatisierungsbeispiel ist hier zu finden.

Vergleich Ant und Maven

Im Vergleich des Aufwands liegen die beiden build-Werkzeuge circa gleich auf. Bei Maven muss zwar das benötigte JAR-Archiv noch in das lokale Repository gespeichert werden, allerdings ist dieser Aufwand auch nur einmalig da. Die Ausführung der einzelnen Tests wird dann mit Hilfe von JUnit-Testfällen vollzogen und ist somit leicht integrierbar.

Einführendes Beispiel

Da UISpec4J auf JUnit aufsetzt, sind die TestCases einfache JUnit TestCases. Die getestete Beispielappikation zeigt anhand einer einfachen GUI die Implementierung einer JUnit-Testklasse "MyTest", in welcher vier beispielhafte Testmethoden implementiert sind, welche die Funktionalität von UISpec4J nutzen. Hier zwei Beispiele:

bild1

UISpec4j.init() wird benötigt, damit aufpoppende Fenster eingefangen werden können. Diese Funktionalität ist unter Linux nicht lauffähig.
Nachdem das Panel dem UISpec4J hinzugefügt wurde, wird mit testThisOne.getButton("Count").click(); der Button geklickt.
assertTrue(testThisOne.containsLabel("Counter : 1").isTrue()); prüft, ob ein Label mit dem Text "Counter : 1" existiert. Hier zeigt sich auch eines der großen Mankos von UISpec4j: Es kann Out-of-the-Box nicht überprüfen, welches Label diesen Wert hat, sondern nur, ob ein Label mit den Eigenschaften existiert.

combobox

Hier zeigt sich die gleiche Problematik wie oben: Die Combobox, die auf dem Panel enthalten ist, wird auf den Wert "Student" gesetzt, existieren zwei Comboboxen, wird eine Exception geworfen.

Wird die Testklasse als JUnit-Test ausgeführt, kommt es zu folgenden Meldungen durch JUnit:

Unter Windows: erfolgreich
success