Automatisierte Tests sind aus der Softwareentwicklung nicht mehr wegzudenken. Das gilt selbstverständlich auch für den Test von Benutzeroberflächen.

1. Plus CD! Highlights von EclipseCon und Jax 2010 >> 8
4.10
www.eclipse-magazin.de
Exklusiv auf CD:
Eclipse MP3 Manager Sinnkrise oder Innovationstreiber:
Quo vadis
RCP-Applikation gebaut mit
Maven Tycho
Eclipse?
Eclipse SDK 4.0
Eclipse Pulsar
Eclipse SOA Platform
Appcelerator
Titanium 1.2
ceno 0.0.4
Opensocial Gadgets
Social Media für e4 und Google Wave
>> 74
Sond erdruck
Mike Milinkovich:
Maven Tycho „Wir mussten bei der eclipse
>> 54
Schaffe, schaffe, Eclipse baue!
Foundation den Gürtel
Pulsar & Eclipse Mobile >> 28 enGer schnallen.“ >> 24
Entwicklung für iPhone, Android & Co.
RCP-Testing Navigationsbäume
Qualitätssicherung durch mit lunaRCP
automatisierte SWTBot-Tests >> 85
Baumkunde für Einsteiger >> 90
Eclipse Modeling Eclipse Target Platform
Model-2-Text-Transformationen >> 42 Was bringt Eclipse Helios? >> 68

2. Sonderdruck
Rich Client Platform SWTBot
Qualitätssicherung von Geschäftsanwendungen
durch automatisierte SWTBot-Tests
automatisierte
sWtbot-tests
>> dr. reik oberrath
Liste von Anwendern und einen Button.
Automatisierte Tests, die mit dem Continuous Build ausgeführt werden, Der Inhalt der Liste hängt von der Rol-
le des eingeloggten Benutzers ab, wobei
sind aus der Softwareentwicklung nicht mehr wegzudenken. Leider er-
lediglich der Administrator alle Benut-
schwert das Testframework der aktuellen Eclipse-Version 3.5 das Aufset- zer sehen kann. Nach Selektion eines
zen von automatisierten GUI-Tests sehr. Das Hauptproblem besteht darin, Anwenders in der Liste und einem Klick
auf den Button How are you? öffnet
dass das Eclipse-Testframework der Version 3.5 unter JUnit4 nicht läuft sich ein Userdialog mit einem Text, der
[1]. Allerdings hat die Verwendung von JUnit3 zur Folge, dass SWTBot- von der vorherigen Selektion abhängig
ist. Unter dem Menüpunkt File gibt es
Tests zunächst nicht ausgeführt werden können [2], [3]. Zusätzlich bringt die Möglichkeit, sich mit einem anderen
die Verwendung von Log-in-Masken Schwierigkeiten mit sich. Dieser User einzuloggen (Relogin). Für den Ad-
ministrator zeigt das Hauptmenü den
Artikel stellt als Beispiel für eine Geschäftsanwendung die Applikation
zusätzlichen Menüpunkt Administra-
„howareyou“ zusammen mit ihrem Build-Prozess und SWTBot-Tests vor. tion an (Abb. 1).
Von diesen Voraussetzungen ausgehend wird gezeigt, wie die drei Tech- Der Kern der Anwendung ist auto-
generiert und wurde mit dem Wizard
nologien Eclipse RCP, SWTBot und JUnit3 „verheiratet“ werden können, „New Plugin-Project“ und der Einstel-
um SWTBot-Tests automatisiert mit dem Build-Prozess auszuführen. lung Would you like to create a new
rich client application? sowie dem
Tem plate RCP application with a
D ie hier beschriebene Beispielan-
wendung howareyou ist eine ein-
fache RCP-Anwendung mit Loginmas-
Logging-Mechanismus (log4j). Beim
Login erfolgt eine Userauthentifizie-
rung. Die howareyou-View zeigt Daten
view erzeugt. Die Loginmaske ist als Di-
alog implementiert und wird im Appli­
cationWorkbenchAdvisor aufgerufen
ke, Hauptmenü, einer View und einem des eingeloggten Benutzers, enthält eine (Listing 1). Beim Relogin wird die Me-
2 eclipse magazin 4.10 © Software & Support Verlag GmbH www.eclipse-magazin.de

3. SWTBot Sonderdruck
Rich Client Platform
thode updateGuiWithUserPermission()
aufgerufen.
Da beim ersten Login noch keine
Shell vorhanden ist, wird zur Initialisie-
rung des Logindialogs immer eine neue
Shell erzeugt (Listing 2). Im Fall eines
Relogins wird die Shell der Anwendung
unsichtbar gemacht.
Galileo ermöglicht mit mäßig gro-
ßem Aufwand, einen Ant-Build-Prozess
aufzusetzen, mit dessen Hilfe eine RCP-
Anwendung automatisch (headless)
gebaut werden kann [4], [5]. In einem
Build-Verzeichnis müssen alle Eclipse-
Projekte, die zur Anwendung gehören,
nach Plug-ins und Features sortiert in Abb. 1: Loginmaske, View und Userdialog der „howareyou“-Anwendung
gleichnamigen Unterverzeichnissen
vorliegen. Das howareyou-Build-Skript ßerdem ein Test-Base-Projekt, das Ba- Stammklasse AbstractSWTBotTest ab.
erzeugt diese Verzeichnisstruktur und sisfunktionalität zur Implementierung Der Konstruktor dieser Stammklasse
außerdem auch ein spezielles Target- von Tests zur Verfügung stellt, und prüft, ob die Loginmaske zu bedienen
Verzeichnis für den Build-Prozess (Ta- schließlich ein Testfragmentprojekt, ist und führt gegebenenfalls den Login
belle 1). das die eigentlichen howareyou-Tests mit einem Standarduser durch. Auf die-
Zu diesem Artikel gehören die Sour- beinhaltet. Die Architektur des how­ se Weise braucht nicht jeder Einzeltest
cen der Beispielanwendung howareyou, areyou-Testframeworks beruht auf der den Login zu implementieren und kann
die unter [6] heruntergeladen werden Verwendung von Fragmenten [7]. Bei trotzdem einzeln ausgeführt werden.
können. Diese Sourcen beinhalten die dieser Architektur bekommt jedes zu Nach dem Login selektieren die how­
Beispielanwendung in drei verschiede- testende Plug-in ein Fragment, das alle areyou-SWTBot-Tests einen Benutzer in
nen Entwicklungsstadien. Tabelle 2 gibt Plug-in-spezifischen Test-Sourcen bein- der Liste und betätigen den howareyou-
darüber einen Überblick. haltet. Alle Testklassen des Fragments
Die howareyou1-Sourcen beinhal- werden zu einer Test-Suite vereinigt und Listing 1
ten vier Projekte. Das Projekt com.iks_ die Suites der einzelnen Testfragmente public class ApplicationWorkbenchAdvisor extends
gmbh.howareyou.app (später app-Plug- werden in einer globalen Suite verei- WorkbenchAdvisor {
in genannt) beinhaltet den Quellcode nigt, die sich in einem speziellen Test- ...
der Anwendung und die Produktkonfi- Plug-in befindet. Der Start der globalen @Override
guration. Dazu gibt es ein Featurepro- Suite kann so alle vorhandenen Tests im public boolean openWindows() {
LoginDialog.setApplicationWorkbenchAdvisor(this);
jekt, daneben ein Build-Projekt für den Workspace ausführen. Voraussetzung
LoginDialog.login();
automatischen Build-Prozess und ein dafür ist, dass die benötigten SWTBot-
updateMainMenu();
Environment-Projekt, aus dessen zip- Sourcen im Target-Verzeichnis der Ent- return super.openWindows();
Dateien der Build-Prozess das Target- wicklungsumgebung enthalten sind. }
Verzeichnis erzeugt, falls es nicht schon Dabei handelt es sich um den Inhalt der
vorhanden ist. org.eclipse.swtbot.eclipse-Zip-Datei, public void updateGuiWithUserPermissions() {
die sich im Environment-Projekt der updateMainMenu();
die manuellen sWtbot-tests howareyou2-Sourcen befindet. View.updateContent();
}
Die howareyou2-Sourcen beinhalten Die Implementierung der SWTBot- }
drei weitere Projekte: ein Testprojekt, Tests wurde mit Page-Objekten reali-
mit dessen Hilfe alle Tests im Work- siert [8]. Außerdem leiten alle howare­
space zusammengefasst werden, au- you-Testklassen von der gemeinsamen
Listing 2
public class LoginDialog extends Dialog {
buildHowareyouApplication führt initBuild aus und startet dann den eigentlichen Build ...
public static boolean login() {
initBuild erzeugt das Build-Verzeichnis, führt buildTargetIfNot-
final Display d =
Present und initBuildOutputDir aus
PlatformUI.getWorkbench().getDisplay();
buildTargetIfNotPresent prüft Target-Verzeichnis und führt ggf. BuildTargetFrom- final Shell shell = new Shell(d);
EnvironmentDir aus if (applicationShell != null)
applicationShell.setVisible(false);
buildTargetFromEnvironmentDir erzeugt das Target-Verzeichnis und entpackt die Zip-Files (new LoginDialog(shell)).open();
initBuildOutputDir kopiert alle Feature- und Plug-in-Projekte in die feature- return true;
und plugin-Unterverzeichnisse des Build-Verzeichnisses }
}
Tabelle 1: Liste der Targets des „howareyou“-Build-Skripts
www.eclipse-magazin.de © Software & Support Verlag GmbH eclipse magazin 4.10 3

4. Sonderdruck
Rich Client Platform SWTBot
Button. Anschließend wird der Inhalt des füllt die Loginmaske aus und klickt den wendung eingebaut werden. Aus die-
angezeigten Userdialogs auf Richtigkeit OK-Button. Das führt dazu, dass die sem Grund enthalten die howareyou3-
überprüft. Beim Ausführen der SWTBot- howareyou-Anwendung ihr Applikati- Sourcen ein neues Testfeatureprojekt,
Tests ist es wichtig, im Launcher die Op- onsfenster erzeugt. Parallel dazu beginnt das alle Test-Plug-ins beinhaltet. Da
tion Run in UI Thread zu deaktivieren die Testausführung, die ein bestimmtes es wünschenswert ist, die Anwendung
und unter der Option Run a product auch ohne Test-Sourcen bauen zu kön-
das howareyou-Produkt auszuwählen. nen, ist jetzt eine zweite Produktkonfi-
Tut man das mit den howareyou1-Sour- guration hilfreich, die neben dem app-
cen, steht man vor einem Thread-Prob- Das zweite Build- Feature für die Plug-ins der eigentlichen
lem. Anwendung auch das Testfeature be-
Bevor die SWTBot-Test-Sourcen Skript enthält inhaltet. Diese Produktkonfiguration
ausgeführt werden, wird die zu testen- heißt in den howareyou3-Sourcen how­
de RCP-Anwendung gestartet. Für den Ant Targets für die areyou.test.product und befindet sich,
Start der Anwendung muss die Methode wie die erste Produktkonfiguration, im
Workbench.init() ausgeführt werden, Testausführung. app-Plug-in.
die wiederum die Methode Application­ Das bisherige Build-Skript bleibt
WorkbenchAdvisor.openWindows() bis auf die oben genannte Änderung im
aufruft. Diese Methode wartet aber we- buildTargetFromEnvironment Target
gen der Loginmaske auf eine Usereinga- Widget sucht. Sobald das Applikations- unverändert und kann benutzt werden,
be (Listing 1). Da deshalb der howare­ fenster zur Verfügung steht, findet der um die howareyou-Anwendung ohne
you-Start stehen bleibt, laufen die Tests SWTBot-Test das Widget, und die Test- Test-Sourcen als Release Candidate zu
nicht an. Die Loginmaske braucht also ausführung beginnt. bauen. Im Verzeichnis test des Build-
ihren eigenen Thread. Listing 3 zeigt, wie Projekts findet sich in den howareyou3-
das geht. die automatischen sWtbot-tests Sourcen ein zweites Build-Skript, das das
Damit das Applikationsfenster erst Für die automatische Ausführung der erste Build-Skript benutzt, um die how­
nach dem Login erzeugt wird, wird die Tests werden noch zusätzliche Quell- areyou-Anwendungen als automatisch
Methode WorkbenchAdvisor.open­ codes benötigt. Im Wesentlichen han- testbare Version zu bauen. Dieses zweite
Windows() jetzt nicht mehr in der Me- delt es sich dabei um die Eclipse-Test- Build-Skript enthält Ant Targets für die
thode ApplicationWorkbenchAdvisor. Framework-Sourcen (ETF) und spezielle Testausführung und hat außerdem ei-
openWindows() aufgerufen (Listing 1), SWTBot-Sourcen (org.eclipse.swtbot. ne eigene Properties-Datei, die die neue
sondern nach erfolgreichem Login vom eclipse.test). Das Environment-Projekt Produktkonfiguration howareyou.test.
Logindialog über die Methode Appli­ der howareyou3-Sourcen enthält alle product referenziert. Jedes Build-Skript
cationWorkbenchAdvisor.reallyOpen­ benötigten Quellcodes für die automati- benutzt also eine eigene Produktkonfi-
Windows() (Listing 4). sche Testausführung. guration.
Auf diese Weise startet das Eclipse- Diese zusätzlichen Sourcen müs- Die Testausführung besteht aus drei
Framework die howareyou-Anwen- sen im Target der Eclipse-IDE zur Ver- Phasen. In der ersten Phase wird eine so
dungen ohne Applikationsfenster (aber fügung gestellt werden. Deshalb muss genannte Testumgebung gebaut. Für den
mit Logindialog). Danach beginnt der das Ant Target buildTargetFromEnvi­ Bau der Testumgebung wird die howare­
SWTBot-Test und stellt bei seiner Ini- ronment im Build-Skript entsprechend you-Zip-Datei (das Resultat des voran-
tialisierung fest, dass eine Loginmaske erweitert werden. Außerdem müssen gegangenen Build-Prozesses) entpackt.
bedient werden muss. Der SWTBot-Test alle benötigten Test-Sourcen in die An- Zusätzlich zu diesen Applikations-
howareyou1 howareyou2 howareyou3 Beschreibung
app X X X Plug-in mit den Sourcen der Anwendung
app.test.fragment - X X Fragment für die Test-Cases des app-Plug-ins
app.feature X X X Feature mit allen Plug-ins, die für ein Release nötig sind
build X X X Sourcen des automatischen Build-Prozesses
environment X X X Speicherort aller nötigen jar- und zip-Dateien, um eine Run-
time- oder Entwicklungsumgebung einzurichten
test - X X Plug-in für die globale Test-Suite
test.base - X X Plug-in für die Basisfunktionalität der Tests
test.feature - - X Feature mit allen Plug-ins, die zur Testausführung nötig sind
Beschreibung Anwendung Anwendung mit Anwendung mit au-
ohne Tests manuellen Tests tomatischen Tests
Tabelle 2: Übersicht über die „howareyou“-Sourcen und die darin enthaltenen Eclipse-Projekte
4 eclipse magazin 4.10 © Software & Support Verlag GmbH www.eclipse-magazin.de

5. SWTBot Sonderdruck
Rich Client Platform
Sourcen werden verschiedene andere zur Verfügung steht, muss die Testaus- Skript automatisch gebauten Anwen-
Sourcen (im wesentlichen SWTBot- und führung auf JUnit3 umgestellt werden. dung zu den Eclipse-Java-Develop-
ETF-Sourcen) dazu kopiert. Die fertige Diese Umstellung ist leider aufwändig. ment-Tools (JDT) müssen vollständig
Testumgebung findet sich im Build-Ver- Zunächst müssen in den howareyou- gelöscht werden. Die Abhängigkeiten
zeichnis unter testOutputeclipse. In der Projekten alle JUnit4-Abhängigkeiten zu den SWTBot-Sourcen sind aber un-
zweiten Phase werden die eigentlichen durch JUnit3 ersetzt werden. Das be- bedingt nötig. Deshalb muss der SWT-
Tests ausgeführt und in der dritten die trifft folgende Projekte: Bot-Quellcode ausgecheckt und genau-
Ergebnisse zusammengefasst, analysiert so wie die howareyou-Sourcen wie eben
und in einer XML-Datei (results.xml) • com.iks_gmbh.howareyou.test beschrieben auf JUnit3 umgestellt wer-
bereitgestellt. Diese Ergebnisdatei fin- • com.iks_gmbh.howareyou.test.base den. Wie Auschecken und Kompilieren
det sich nach der Testdurchführung im • com.iks_gmbh.howareyou.test.feature funktionieren, ist unter [9] und [10]
Build-Verzeichnis unter testOutput/re­ • com.iks_gmbh.howareyou.app.test. beschrieben. Anschließend wird der
sults. Für die Phasen zwei und drei halten fragment SWTBot-Sourcecode neu kompiliert
die Eclipse-Test-Framework-Sourcen in und dann der howareyou-Anwendung
der Datei library.xml verschiedene Ant Diese Umstellung hat folgende Codean- wieder zur Verfügung gestellt.
Targets bereit. Diese Targets wurden für passungen zufolge: Die howareyou3-Sourcen beinhalten
howareyou angepasst und stehen in der auf diese Weise modifizierte SWTBot-
gleichnamigen Datei im Build-Projekt • AbstractSWTBotTest von junit.frame­ Sourcen für den SWTBot-Build 433. Wer
unter test zur Verfügung. Wichtigste work.TestCase ableiten eine jüngere Version von SWTBot benö-
Änderung in dieser Datei ist ein speziel- • Importanweisungen für org.junit.As­ tigt, muss diese JUnit-Modifizierung
les Target zum Ausführen der SWTBot- sert.assertEquals entfernen selbst vornehmen. Allerdings stehen für
Tests (Listing 5). das SWTBot-Eclipse-Test-Zip-File be-
reits verschiedene Versionen für JUnit3
die umstellung auf Junit3
Würde Eclipse 3.5 und das zugehörige Abhängigkeiten und JUnit4 zur Verfügung, sodass zu-
künftig nur noch das SWTBot-Eclipse-
Testframework JUnit4 richtig unter-
stützen, wäre eine automatische Test-
zu den SWTBot- Zip-File für JUnit3 modifiziert werden
muss.
ausführung jetzt möglich. Das ist leider
nicht der Fall. Die Probleme mit JUnit4
Sourcen sind Nach diesen Umstellungen laufen die
SWTBot-Tests allerdings immer noch
äußern sich darin, dass in den Testklas-
sen keine Testmethoden gefunden wer-
unbedingt nötig. nicht automatisch. Auch die manuell ge-
starteten Tests funktionieren nach die-
den, oder dass eine ClassCastException sen Umstellungen nicht mehr. Der Fehler
ausgegeben wird, weil bei der Testaus- ist im manuellen wie im automatischen
führung versucht wird, JUnit3- und • JUnit4-Annotierungen und ihre Im- Fall derselbe: Die SWTBot-Sourcen kön-
JUnit4-Klassen aufeinander zu cas- portanweisungen entfernen nen die Klasse SWT nicht finden, und es
ten. Ein weiteres Problem ist, dass der wird eine ClassNotFound Excep tion
OSGi-Container bei der Testausfüh- Weitere JUnit4-Abhängigkeiten, die die geworfen. Dieses Problem kann nicht
rung die Test-Fragment-Plug-ins nicht Testausführung unter JUnit3 verhin- durch Zuweisen eines SWT-Plug-ins als
laden kann, weil nicht näher benannte dern, finden sich in den JDT-Sourcen Abhängigkeit gelöst werden. Allerdings
Constraints mit dem Host existieren. Da und den SWTBot-Sourcen. Mögliche kann es sehr einfach durch folgenden
JUnit4 für automatische Tests also nicht Abhängigkeiten der durch das Build- Eintrag in die Manifest-Datei des test.
Listing 3 Listing 4 Listing 5
public static boolean login() { public class ApplicationWorkbenchAdvisor extends <target name="swtbot-test"
final Display d = WorkbenchAdvisor { description="Launches SWTBot
PlatformUI.getWorkbench().getDisplay(); ... tests." depends="init">
final Shell shell = new Shell(d); @Override <echo> Running SWTBot tests... </echo>
Runnable loginRunnable = new Runnable() { public boolean openWindows() { <antcall target="eclipse-test">
LoginDialog.setApplicationWorkbenchAdvisor(this); <param name="application"
public void run() {
LoginDialog.login(); value="org.eclipse.swtbot.eclipse.junit3.headless
(new LoginDialog(shell)).open();
return true;
if (applicationShell != null) .swtbottestapplication"/>
}
applicationShell.setVisible(false); <param name="testApplication" value=
} "com.iks_gmbh.howareyou.app.application"/>
public void reallyOpenWindows() {
}; </antcall>
super.openWindows();
d.asyncExec(loginRunnable); updateMainMenu(); </target>
shell.forceActive(); }
return true; ...
} }
www.eclipse-magazin.de © Software & Support Verlag GmbH eclipse magazin 4.10 5

6. Sonderdruck
Rich Client Platform SWTBot
base-Plug-ins gelöst werden: Eclipse­ tische SWTBot-Tests ausgeführt. Der
Dr. Reik Oberrath ist als IT-Berater
RegisterBuddy: org.eclipse.swt bot. Continuous Build startet mit jeder Än- bei der iks Gesellschaft für Informa-
swt.finder. Dieser Eintrag ermöglicht derung im Repository. Zusätzlich gibt tions- und Kommunikationssysteme
den SWTBot-Sourcen, auf die test.base- es einen Nigthly Build, der die gleichen tätig. Er beschäftigt sich seit vielen
Sourcen zuzugreifen und damit die SWTBot-Tests auf dem richtigen Client Jahren mit der Entwicklung von
SWT-Klasse zu finden. (ein Client ohne Mock-Remote-Objek- individuellen Geschäftsanwendungen, speziell
Mit dieser letzten Anpassung laufen unter Swing und RCP. Besonderen Fokus legt er
die SWTBot-Tests unter JUnit3 sowohl auf Automatisierung in der Qualitätssicherung.
Kontakt: r.oberrath@iks-gmbh.com
manuell im Eclipse Launcher als auch
automatisch im Build-Prozess. Bei der Unter Helios sollte
Konfiguration des Launchers sind fol-
gende drei Punkte zu beachten: automatisiertes Links & Literatur
• Im Tab 'test' muss der JUnit-Runner Testen deutlich [1] https://bugs.eclipse.org/bugs/
show_bug.cgi?id=153429
für JUnit3 gewählt werden
• Im Tab 'test' muss die Option Run in einfacher sein. [2] https://bugs.eclipse.org/bugs/
show_bug.cgi?id=220812
UI thread deaktiviert werden [3] http://swtbot.org/bugzilla/
• Im Tab 'main' muss die Option Run a show_bug.cgi?id=79
product gewählt und ein howareyou- [4] http://www.vogella.de/articles/
Produkt ausgewählt werden te) ausführt. Dieser Client kontaktiert EclipsePDEBuild/article.html
einen Testserver, hinter dem eine leere [5] http://help.eclipse.org/help32/index.
automatische Gui-tests im Testdatenbank steht. Die SWTBot- jsp?topic=/org.eclipse.pde.doc.user/
entwickleralltag Tests erzeugen, laden, bearbeiten und guide/tasks/pde_product_build.htm
Die in diesem Artikel dargestellten löschen Geschäftsobjekte und führen [6] Quellcodes der Beispielanwendung
Probleme und ihre Lösungen waren damit Systemtests automatisch durch, howareyou: Eclipse Magazin 4.10:
http://it-republik.de/jaxenter/
Teil der Qualitätssicherung einer Ge- weil hinter dem getesteten Client ein
eclipse-magazin-ausgaben/
schäftsanwendung, die aus einem RCP- voll funktionsfähiges System steht.
[7] Dilger, Martin: „RCP-Tests mit Fragmen-
Client und einem EJB3-basierten Server ten“, in Eclipse Magazin 4.09, S. 80
besteht. Der Datenaustausch zwischen ausblick
[8] http://it-republik.de/jaxenter/
Client und Server erfolgt über RMI. Ab Eclipse 3.6 soll das Eclipse-Test- artikel/2275
Der Client kann so gebaut werden, framework mit JUnit4 funktionieren [1]. [9] http://wiki.eclipse.org/SWTBot/
dass er mithilfe von Mock-Remote- Unter Helios sollte das Aufsetzen von Contributing
Objekten selbst den Server simuliert. automatischen Tests für RCP-Anwen- [10] http://wiki.eclipse.org/SWTBot/
Auf diesem so genannten Democlient dungen also deutlich einfacher sein. Wir Maintaining_SWTBot_Versions_
werden im Continuous Build automa- werden sehen, ob das auch zutrifft. For_Your_Team
iks Gesellschaft für
Informations-und
Kommunikationssysteme mbH
Siemensstraße 27
40721 Hilden
http://www.iks-gmbh.com
6 eclipse magazin 4.10 © Software & Support Verlag GmbH www.eclipse-magazin.de