Jubeln mit Jubula - GUIdancer

Plus CD!
Paralleles Hosting Ihrer Website
in zwei Hightech-Rechenzentren
an verschiedenen Orten!
✓ Superschnell:
✓ Zukunftssicher:
210 GBit/s Anbindung!
1.000 Mitarbeiter!
1&1 DUAL HOSTING
VIELE PAKETE JETZT SCHON AB
0,–
€/Monat*
Dual Hosting gibt´s nur von 1&1! Kein anderer bietet Ihnen georedundante Sicherheit und maximale Performance für Ihre Projekte.
1&1 DUAL
PERFECT
� 6 Domains aus .de, .com, .net, .org, .at, .eu
� 5 GB Webspace
� UNLIMITED Traffic
� UNLIMITED Click & Build Apps uvm.
.DE, .EU, .COM, .NET, .ORG, .AT
OHNE EINRICHTUNGSGEBÜHR!
Weitere leistungsstarke
1&1 Dual Hosting-Pakete
und tolle Sparangebote
unter www.1und1.info
0 26 02 / 96 91
0800 / 100 668
ab
0,–
€
In den ersten 3 Monaten,
danach 9,99 €/Monat.*
0,
29*
€/Monat
im ersten Jahr
Ausgabe 08/11
Deutschland € 9,80
Österreich € 10,80, Schweiz sFr 19,20
www.eclipse-magazin.de
Eclipse & Java 7 • OSGi und REST • Eclipse Gyrex • Schwerpunkt Testen • Von Swing nach RCP/RAP
&
✓ Maximal sicher:
6.11
6.2011
DOPPELT SICHER!
DOPPELT GUT...
>> Interpreter und Debugger für DSLs >> 93
eclipse magazin
1&1 DUAL HOSTING
>> BONUSVIDEO AUF CD
Was ist neu bei der
Eclipse Rich Client
Platform 4.0?
von Kai Tödter
Java 7 all inclusive!
Fünf Gratisartikel
zum Thema
Java 7
OSGi und REST
>> 22
CLIPSE
E
N
I
T
R
UPPO
JAVA-7-S
Architekturentwurf mit OSGi
Declarative Services und REST
Eclipse Gyrex
>> 39
Platform as a Service für die eigene Cloud
Von Swing nach RCP/RAP
>> 31
Alle Infos im
Heft!
Portierung einer Swing-Anwendung nach Eclipse RCP/RAP
SCHWERPUNKT TESTEN
www.1und1.info
* 1&1 Dual Perfect 3 Monate für 0,– €/Monat, danach 9,99 €/Monat. Einrichtungsgebühr 9,60 €. Domains im ersten Jahr .de, .eu 0,29 €/Monat, .com, .net, .org, .at 0,99 €/Monat, danach .de
0,49 €/Monat, .eu , .com, .net, .org 1,49 €/Monat, .at 1,99 €/Monat. Einrichtungsgebühr entfällt. 12 Monate Mindestvertragslaufzeit. Preise inkl. MwSt.
• GUI-Tests für Web- und AJAX-Applikationen >> 67
• Automatisierung modellbasierter Testszenarien
• Clever Testen mit Eclipse Jubula >> 58
>> 76
Testen
Jubula
Automatisierte GUI-Tests mit Intelligenz, Durchhaltevermögen und einem
leichten Touch Paranoia
Clever Testen:
Jubeln mit Jubula
„Testdesign macht Spaß, Testausführung nicht“: O-Ton aus dem Birds-Of-A-Feather-(BOF-)Gespräch auf der EclipseCon 2011 in Santa Clara. Obwohl über vieles lebhaft diskutiert wurde,
war diese Aussage eine der wenigen, die allgemeine Zustimmung fand. Menschen sind eben
kreativ und können sich jede Menge spannender Fälle (oder auch Fallen) ausdenken, um eine
Anwendung auf die Probe zu stellen. Bei der ersten Ausführung ist alles noch mitreißend, aber
das Interesse lässt schnell nach. Doch dafür gibt es die Testautomatisierung. Sie soll uns diese
langweiligen Wiederholungen ersparen. Aber muss es dann stimmen, dass die stumpfe Arbeit der
Ausführung durch die Schufterei der Pflege ersetzt wird? Nicht mit Jubula.
von Alexandra Schladebeck
Durch die Verbreitung von JUnit ist „Testen“ längst
kein Unwort mehr. Wir müssen allerdings zugeben,
dass unsere JUnit-Tests uns nicht vor holprigen Workflows, defekten Anwendungsfällen beziehungsweise
Geschäftslogik oder peinlichen UI-Fehlern durch das
Zusammenspiel verschiedener Plug-ins retten können.
Der Anwendungsbereich von Eclipse steigt und damit
auch die Komplexität der Anwendungen, die darauf basieren. Jede Anwendung, die für Enduser vorgesehen ist,
58
eclipse magazin
6.11
muss gründlich aus dieser Perspektive getestet werden.
Je früher sich eine Anwendung gegenüber ihren Akzeptanzkriterien rechtfertigen muss, desto besser. Wenn
wir solche Tests automatisieren, bekommen wir auch
die Möglichkeit, nach Änderungen den Qualitätsstatus
mit Regressionstests erneut zu überprüfen.
Das gibt es doch schon!
Jubula ist nicht das erste Tool, das sich mit dem Thema
„GUI-Tests“ beziehungsweise „Tests durch die GUI“
auseinandersetzt. Ohne hier auf die technischen und die
www.eclipse-magazin.de
Testen
Jubula
häufig philosophischen Unterschiede zwischen solchen
Tools einzugehen, kann man zwei Merkmale erwähnen,
die Jubulas Ansatz und Nutzen doch hervorheben. Der
erste Unterschied ist die Abwesenheit von Programmcode in den Tests. Jubula richtet sich in erster Linie
an Teams, die eine Testautomatisierung aus fachlicher
Sicht wünschen, um ihre Anwendungen als Blackbox zu
behandeln. Allerdings wird diese fachliche Sicht nicht
durch das Aufzeichnen manueller Aktionen in der Anwendung automatisiert. Die verschiedenen Kritikpunkte
für diesen Capture-Replay-Ansatz lassen sich in diesen
wenigen Seiten nicht auflisten, sondern man sollte sie
lieber in einem unserer Blogeinträge nachlesen [1]. Kurz
gefasst: Statt aufzuzeichnen arbeitet Jubula mit einem
Satz vorgefertigter Aktionen, die sich hierarchisch zu
flexiblen, aber auch lesbaren automatischen Tests per
Drag and Drop kombinieren lassen.
Ein Vorteil dieses Ansatzes liegt darin, dass Tests
sehr früh automatisiert werden können (sogar noch
vor Beginn der Featureentwicklung). Der Verzicht auf
Aufnehmen bedeutet, dass man nicht auf eine lauffähige Version der Anwendung warten muss. Außerdem
werden Tests eher geplant und strukturiert entworfen,
wenn sie händisch erstellt statt aufgenommen werden.
Früher oder später müssen Tests intelligent, wartbar
und robust sein (hierzu später mehr). Den Weg dahin
kann man sich nicht sparen, sehr wohl aber versüßen:
Mit dem Jubula-Ansatz spezifiziert man bereits von Anfang an Tests, die einen grundlegenden Wiederverwendungsgedanken besitzen. Das reduziert den folgenden
Pflegeaufwand deutlich.
Herunterladen, konfigurieren, austoben
Entwickler von Swing-, SWT/RCP- und HTML-Anwendungen, denen dieser Ansatz zusagt, können sich Jubula
von der Eclipse-Jubula-Seite [2] herunterladen. Jubula
gibt es dort als Teil des „Eclipse for Testers“ Package,
über eine Updatesite sowie als eigenständige Anwendung. Letzteres ist für den HTML-Bereich zu empfehlen, denn die Ausführungskomponente für Webtests
ist Selenium, das sich aus Lizenzgründen nicht in das
Eclipse Package einbinden lässt. Über den MarketPlace
[3] bekommt man die notwendigen Datenbanktreiber,
um auch mit der Plug-in-Version eine Multi-User-Datenbank wie Oracle statt der mitgelieferten EmbeddedH2-Datenbank verwenden zu können.
Tabula rasa
Nach erfolgreicher Installation sieht die Anwendung mit
ihrer leeren Perspektive noch recht karg aus. Die Schritte
zum ersten laufenden Test sind glücklicherweise wenige
und einfach. Es muss zunächst ein Projekt angelegt und
(falls schon vorhanden) eine zu testende Anwendung
(AUT) konfiguriert werden (Abb. 1). Das Schreiben von
Tests beginnt mit der Selektion der gewünschten Aktionen aus der Bibliothek (z. B. zweimal replace text und
einmal single left click, um einen Logindialog zu bedienen). Die frisch verwendeten Aktionen müssen für ih-
www.eclipse-magazin.de
Abb. 1:
AUT-Konfiguration
ren aktuellen Verwendungszweck dann konkretisiert
werden, etwa um Daten oder Platzhalter für Daten,
sprechende Namen für Lesbarkeit und eine symbolische
Bezeichnung für das Objekt (die Komponente in der
AUT), das zur Laufzeit bedient werden soll (Abb. 2). Ein
so geschriebener Test wird ausführbar gemacht, indem
alle fehlenden Daten noch eingetragen werden (gerne aus
wiederverwendbaren Datentabellen) und das geheimnisvolle Object Mapping durchgeführt wird. Dieser letzte
Schritt ist die Magie der Automatisierung und verbindet
einen im Test deklarierten symbolischen Namen mit einem echten Objekt aus der Anwendung (Abb. 3).
Nicht nur schreiben, entwerfen
Die Details zur Testfallerstellung sind absichtlich etwas schnell überflogen worden. Schließlich wollen wir
Namensgebung in Jubula
Swing: In Swing/AWT wird, falls vorhanden, der Name der java.awt.
Component benutzt. Über die Methode setName() unterstützt bereits das
API die Vergabe eindeutiger, nach außen hin unsichtbarer Komponentennamen.
SWT/RCP: SWT/RCP Controls besitzen ein solches API nicht. Die Klasse
Widget verfügt jedoch über die Methode setData (String key, Object value);. Dadurch kann jeder SWT-Komponente (einschließlich Container wie
Shells oder Composites) eine beliebige Liste von Key-Value-Paaren zugeordnet werden. Der in Jubula zu verwendende Key, um eine Komponente
mit einem eindeutigen Namen zu versehen, lautet TEST_COMP_NAME.
Der dazu zugeordnete Wert muss ein eindeutiger Name für die Komponente sein, beispielsweise setData("TEST_COMP_NAME",
"myUniqueCompName");.
HTML: Zur Identifizierung technischer Komponenten auf HTML-Webseiten
wird standardmäßig das ID-Attribut verwendet. Da dieses Attribut häufig
für frameworkinterne Zwecke eingesetzt wird und die ID-Charakteristik
durch ein dynamisches Verhalten verliert, kann man zusätzlich pro Anwendung ein Attribut definieren, dessen Wert als eindeutiger Name für
die technische Komponente herangezogen wird. Das Attribut muss ebenfalls in der AUT-Konfiguration hinterlegt werden.
eclipse magazin
6.11
59
Testen
Jubula
Abb. 2: Überblick über die Testspezifikation
spannende, flexible und clevere Tests entwerfen, nicht
nur Aktionen linear nacheinander aufreihen. Für die
Einarbeitung in die allgemeine Arbeitsweise gibt es im
Jubula-Help-Menü Cheat Sheets. Die grundsätzlichen
Schritte sind mit ihrer Hilfe schnell gemeistert, und
schon bald kommen wir zum interessanteren Thema
des Testdesigns, besonders in Hinsicht auf Wartbarkeit
und Robustheit. Denn eines muss immer klar sein, ein
automatisierter Test hat
nur dann Wert, wenn
er mit möglichst wenig
Aufwand möglichst viel
aussagt und dabei möglichst lange lebt. Wer
seine
automatischen
Tests nicht wartbar und
robust erstellt, wird generell weniger Informationen aus den Testergebnissen
ziehen können und wird sie zudem früher oder später
ganz verwerfen müssen.
es ankommen, und diese müssen gegebenenfalls auch im
Test abgefragt oder beachtet werden. Jubula legt deshalb
einen besonderen Fokus auf Design, wie die folgenden
kleinen Beispiele zeigen:
•Synchronisation: Auch wenn eine Anwendung schnell
reagiert (Fenster erscheinen und verschwinden „sofort“
und sind beim Öffnen immer komplett aufgebaut), kann
es trotzdem sein, dass ein
Roboter kleine Zeitunterschiede bemerkt und
bemängelt. Wegen solcher Kleinigkeiten darf
aber kein Test fehlschlagen. Dafür gibt es in Jubula eine Reihe an Wait
for…-Aktionen, die ein
dynamisches Warten (über eine Maximalzeit abgebildet) auf bestimmte Ereignisse erlauben. Neben der Tatsache, dass das eine allgemeine Best Practice darstellt,
ist eine gut ausgedachte Synchronisation unverzichtbar,
sobald man Tests von der Kommandozeile startet bzw.
zu testende Anwendungen wechselt oder neu startet.
•Errare humanum est: Nicht nur wegen Synchronisationsproblemen können Tests fehlschlagen. In der
Tat wollen wir, dass ein Test dann fehlschlägt, wenn
etwas Unerwartetes passiert. Allerdings ist es nicht
wünschenswert, deswegen einen ganzen Testausfall
Einem automatischen Test den
Hauch von Intelligenz zu verleihen, ist eine Kunst für sich.
Clevere Tests schreiben
Einem automatischen Test den notwendigen Hauch von
Intelligenz zu verleihen, ist eine Kunst für sich. Ein Tester
muss sich hervorragend mit seiner AUT auskennen, muss
lernen, wie sie in unterschiedlichen Situationen funktioniert, muss kreativ vorgehen und muss auch eine gesunde
Paranoia zeigen können. Auf die kleinsten Details kann
60
eclipse magazin
6.11
www.eclipse-magazin.de
Jubula
zu produzieren. Anwendungsfälle, die von der Abweichung nicht betroffen sind, sollten auch ihre Chance
zum Laufen bekommen. Es verbergen sich in ihnen
unter Umständen noch schlimmere Fehler, die durch
einen Totalausfall maskiert würden. In Jubula wird
das Konzept von Event Handlers verwendet, um Fehler abzufangen, Aktionen im Fehlerfall durchzuführen
(z. B. die AUT neu starten) und Tests an konfigurierbaren Stellen (z. B. beim nächsten Use Case) weiterlaufen
zu lassen. Auch hierzu gehören Best Practices wie zum
Beispiel Unabhängigkeit zwischen Anwendungsfällen
und intelligente Set-up-Module, die eine Anwendung
in den richtigen Zustand für den nächsten Use Case
bringen können (z. B. in Abhängigkeit davon, ob ein
Logindialog oder eine schon laufende Anwendung
vorhanden ist (Abb. 4)).
Pflegeleichte Tests schreiben
Kluge Designs helfen einem allerdings nicht, wenn die daraus resultierenden Tests schwer zu warten sind. Hier folgt
Jubula dem gleichen Grundsatz wie beim Entwickeln: referenzieren statt kopieren (in der Tat ist Copy and Paste
von Tests in Jubula nicht vorhanden). Ob ein fachlicher
Testfall mehrmals gebraucht wird oder ob man merkt,
dass ein Satz an abstrakten Aktionen häufig vorkommt,
gilt das Prinzip „einmal schreiben und dann wiederverwenden“. Hierfür sollten Module möglichst flexibel geschrieben werden:
•Flexible Module bauen: Durch die Möglichkeit, sowohl Daten als auch die zu bedienende Komponente
bei jeder konkreten Verwendungsstelle eines Testfalls
neu festzulegen, lassen sich flexible Module
bilden. Die einzelne Spezifikationsstelle bietet
dann bei Änderungen (und sie werden sicher
kommen) einen zentralen Ort, um alle Tests
nachzuziehen (Abb. 5).
•Refactor!: Unterschiedliche Denk- und Arbeitsweisen werden in diesem Rahmen auch
unterstützt. Manche Tester können von vornherein erkennen, welche Aktionen als wiederverwendbare Module zusammengehören.
Andere bemerken Ähnlichkeiten und daher
den Bedarf an einem Modul erst, wenn die
gleichen Aktionen zum zweiten Mal gebraucht
werden. Über die Refactor-Funktionen lassen
sich Testfälle aus schon bestehenden Aktionssequenzen erstellen. Ein neues Feature in Indigo SR1 ermöglicht eine geführte Ersetzung von
ausgewählten Testfällen, zum Beispiel mit neu
erstellten zentralen Modulen.
•Design for Testability: Robustheit für automatisierte Tests lässt sich nicht nur anhand
der Teststruktur gewährleisten, sondern kann
auch in die AUT hineinprogrammiert werden.
Das beste Beispiel hierfür ist das Benennen von
Komponenten in der AUT. Trotz der Intelligenz
der Objekterkennung kann es vorkommen,
www.eclipse-magazin.de
Testen
Abb. 3:
Object
Mapping
dass Änderungen zu so genannten „Component Not
Found“-Fehlern führen. Das und das anschließend notwendige Neu-Mappen lassen sich verhindern, wenn die
Komponenten eindeutige Namen besitzen. Jubula bietet
hierfür einen Mechanismus (Kasten: „Namensgebung in
Jubula“).
Eindeutige IDs sind zwar der meist gehörte Wunsch für
Testbarkeit, aber sie sind keinesfalls der einzige Weg,
um die Testbarkeit zu erhöhen. Die sinnvolle Benennung von Dialog- und Nachrichtenfenster (damit man
anhand des Titels z. B. synchronisieren kann) sowie die
Tastaturbedienbarkeit einer Anwendung können ebenfalls zu einer besser testbaren AUT führen. Nebenbei
bemerkt führen solche Überlegungen auch zu einer besseren Bedienbarkeit. Auch für die GEF-Unterstützung
in Jubula lassen sich entsprechende Namen für Figure
Abb. 4: Fehlerbehandlung und
Testfortsetzung
eclipse magazin
6.11
61
Testen
Jubula
Abb. 5:
Flexibler
Baustein
zum
Schließen
jeglicher
Dialoge
Das Jubula-Team setzt diese Möglichkeit ein, um den
aktuellen Stand der Tests jede Nacht aus der Versionskontrolle in eine Testdatenbank zu importieren.
Über diese beiden Clients lässt sich Jubula problemlos in Build-Prozesse einbinden. Der firmeninterne Build
des Jubula-Teams verwendet Hudson, um den aktuellen Stand der Software jede Nacht zu bauen, auf verschiedene Testrechner zu installieren und konfigurieren,
Daten und Umgebungen bereitzustellen beziehungsweise
aufzuräumen und die nächtlichen Regressionstests anzustoßen. Morgens können die Ergebnisse direkt in Jubula
oder anhand generierter HTML-Berichte ausgewertet
und analysiert werden.
Ab zum Test
Paths unter Verwendung von org.eclipse.core.runtime.
adapter im Programmcode vergeben.
Build me up, Buttercup
Schlaue Tests zu schreiben ist noch nicht alles. Wenn sie
nicht dafür eingesetzt werden, um jeden neuen Build zu
überprüfen, können sie auch keine vernünftigen Aussagen treffen. Damit automatische Tests erfolgreich in die
Entwicklung integriert werden, müssen sie vom Prozess
her eine angemessene Wichtigkeit erhalten. Von den Tests
aufgedeckte Fehler müssen zum Beispiel mit einer hohen
Priorität behoben werden. So genießt man am besten die
Vorteile des frühen Findens, und die Tests laufen schnell
wieder erfolgreich durch. Das Einbinden von Jubula-Tests
in den automatischen Build-and-Test-Prozess erfolgt über
zwei kommandozeilenbasierte Anwendungen. Der Test
Executor erlaubt das Ausführen einer Test Suite, ohne den
grafischen Client starten zu müssen:
C:/Programme/jubula/jubula/testexec.exe
–data C:/Benutzer/Alex/jubulaWorkspace
–project Samples –version 5.1
–autconfig localhost_system_jre
–dbscheme "Default Embedded (H2)" –dbuser sa –dbpw ""
–server localhost –port 60000
–language en_US
–testsuite 1.1_SIMPLE_ADDER_TEST_WITH_TEST_STEPS
–datadir C:/Benutzer/Alex/Jubula
–resultdir C:/Benutzer/Alex/Jubula
Der Test Executor verbindet sich zum laufenden Agent
(Serverprozess), um die AUT zu starten und die Tests
auszuführen. Über die Integrated Test Environment
(ITE) lassen sich die Ergebnisse im Nachhinein analysieren, inklusive Screenshots bei Fehlern. Ein zweites
Kommandozeilentool, das DBTool, ermöglicht das
Importieren und Exportieren von Tests in und aus der
Datenbank, sowie das Löschen vorhandener Projekte.
62
eclipse magazin
6.11
Wenn wir uns die Langeweile der Testausführung sparen wollen, reicht es nicht aus, lieblos Tests herunter
zu automatisieren. Ein gut automatisierter Test kann
einem Projekt sein ganzes Leben hindurch begleitend
und helfend zur Seite stehen. Testdesign ist eine kreative Aufgabe und sollte von Teammitgliedern durchgeführt werden, die eine Anwendung von ihren besten und
schlechtesten Seiten kennen. Mit Jubula ist das möglich.
Der Fokus auf Zugänglichkeit für fachliche Tester bedeutet aber nicht, dass die Grundsätze der Robustheit
und Wartbarkeit für die Tests ignoriert werden, ganz im
Gegenteil. Jubula bietet verschiedene Mechanismen, um
clevere und langlebige Tests zu schreiben und sie in den
Entwicklungsprozess zu integrieren. Hilfe bei den Feinheiten des Testdesigns und der Festlegung eines geeigneten Testprozesses gibt es beim Jubula- beziehungsweise
GUIdancer-Team.
Nach ihrem Studium der Sprachwissenschaft ist Alexandra Schladebeck (geb. Imrie) seit 2005 bei der BREDEX GmbH in Braunschweig beschäftigt. In ihrer Rolle als Trainerin und Beraterin hilft
sie Kunden bei der Entwicklung von Testprozessen und automatisierten Tests. Sie ist auch Teil des Eclipse-Jubula-Entwicklungsteams
bei BREDEX, wo sie die Kunden- und Benutzerperspektive vertritt. Als Committer für das Jubula-Projekt beschäftigt sie sich mit der Dokumentation und
hilft bei der User-Story-Entwicklung und Qualitätssicherung. Besonders interessiert sich Alexandra Schladebeck neben Benutzerfreundlichkeit und Ergonomie auch für Agilität in Test- und Entwicklungsprozessen.
Links & Literatur
[1] http://bxapps.bredex.de/blog/?p=703
[2] http://www.eclipse.org/jubula/
[3] http://marketplace.eclipse.org/content/eclipse-jubula-database-drivers
www.eclipse-magazin.de
n! in.de
e
r
e
ni agaz
n
o
ab psem
t
z
t
Je w.ecli
ww
ECLIPSE
3
Jetzt 3 Top-Vorteile sichern!
1
Alle Printausgaben frei Haus erhalten
Intellibook-ID kostenlos anfordern
(www.intellibook.de)
2
Mit der Intellibook-ID kostenlos in der App
anmelden und Zugriff auf alle Ausgaben des
Eclipse Magazins erhalten (+ Bonusinhalte!)
Zugriff auf das
komplette PDF-Archiv
mit der Intellibook-ID
3
www.eclipsemagazin.de