Yepp, ja, ich weiss, ich sollte endlich mal eine fertige Version rausbringen und dann anfangen auf jedes (exotische *duck_und_weg*) Betriebssystem zu portieren. Aber ich habe irgendwie so ein wenig rumgedaddelt vorm Rechner und dachte mir ich könnte ja mal Ubuntu runterladen für VMWare Fusion. Gesagt, getan!

Naja, Eclipse war fix installiert und iPlode lief – nach anpassen der SWT-Libraries – out of-the-box, was mich wieder zu meiner Überschrift bringt: Java ist doch was Feines.

Der Plan ist aber immer noch am Wochenende ein wenig Zeit zu investieren, um die ersten Downloads klar zu machen. Ok, jeder der Software entwickelt weiss ja wie das so ist mit den Plänen, aber noch steht der Plan :-).

Project Hosting on Google Code is a free service to the open source community. Featuring a Subversion back-end, wiki support, file downloads, issue tracking and a clean, Google-style interface, our project hosting service is the world’s second largest open source hosting site after SourceForge.net.

Aber zurück zum Test Framework mit dem einprägsamen Namen Robot. Das Projekt bei dem ich Robot genutzt habe liegt etwas mehr als ein Jahr zurück, aber ich glaube ich kann mich an die wichtigsten Features noch ganz gut erinnern.

Also, wofür ein … dieses … Test Framework? Es geht darum einen automatisierten Blackbox-Test für eine Software aufzubauen. Automatische Tests sind ein Herzstück agiler Softwareprojekte, denn nur mit (guten!) automatisierten Tests lässt sich innerhalb einer Iteration sicherstellen, dass alle bereits fertigen Teile der Software immer noch wie erwartet funktionieren – und die neuen Teile natürlich auch. Hierbei gilt es die von der Software zur Verfügung gestellten Interfaces abzutesten (“Gutfälle” und “Schlechtfälle” gleichermassen). Natürlich hängt die Qualität der Tests stark vom Test-Entwickler ab, und das beste Framework kann keine schlechten Tests vermeiden, aber es kann die Implementierung guter Tests unterstützen. Und das tut das Robot Framework ganz gut wie ich finde.

Die Einarbeitungszeit in das Tool war relativ gering. Die Tests lassen sich in einzelnen Modulen implementieren. Dies kann entweder in Java passieren, oder in jeder Sprache, die sich per Shell aufrufen lässt, z.B. Perl. Ein Test erwartet einen gewissen Satz von Parametern, die dann an die Testmethode übergeben werden. Diese Methode implementiert dann den Test und liefert OK oder NOK zurück. Ein Testcase lässt sich aus mehreren solcher Methoden zusammensetzen. Auch kann man die Testcases taggen, um sich in den generierten Reports einen besseren Überblick über die getesteten Teile der Software zu verschaffen … Achtung … die benutzten Keywords müssen gut abgestimmt werden, sonst benutzt jeder leichte Abwandlungen.

Testmethoden lassen sich in einer Art Projekt zusammenfassen, wobei es natürlich sinnvoll ist ähnliche – und vor allen Dingen generische – Testmethoden einmal für mehrere Projekte zu schreiben. Solche Tests könnten z.B. sein: “Existiert eine Datei (Parameter Pfad zur Datei)” oder “Existiert ein Directory (Pfad zum Directory)”. Komplizierte Testcases können so aus einer Vielzahl (idealerweise bereits existierender) Testmethoden zusammengesetzt werden. Die generierten Reports zeigen übersichtlich die Anzahl der erfolgreichen/fehlgeschlagenen Tests an und es lässt sich auch anzeigen welche Tests wo fehlgeschlagen sind.

Was ist sonst noch zu beachten? Die eigentlichen Testcases werden in einer simplen HTML-Datei geschrieben, was die Ganze Sache recht einfach macht. Hier werden nur noch vorhandene Testmethoden genutzt und die Parameter übergeben. Zum eigentlichen schreiben der Testmethoden ist aber im Prinzip eher das Wissen eines Entwicklers als das eines Testers gefragt, denn die Entwicklung der Testmethoden kann sich leicht zu einem eigenen kleinen Software-Projekt entwickeln. Auf der anderen Seite ist es gefährlich wenn der Entwickler die Testmethoden für seine eigenen Komponenten entwickelt. D.h. hier sind Tester mit Programmiererfahrung gefragt oder aber die Testmethoden müssen von verschienden Team-Mitgliedern entwickelt werden. Es ist eh fraglich ob “reine Tester” in agilen Teams sinnvoll sind, insbesondere wenn diese auch noch in externe Teams ausgelagert sind. Ich denke es macht deutlich mehr Sinn Testkompentenz – zusätzlich – im agilen Team aufzubauen und zu nutzen. Dadurch bekommen die “Tester” auch direkt mehr Produktkompentenz und wissen besser welche Schnittstellen es zu testen gilt.

Testen von “Backend-Prozessen” und GUI … das werde ich hier nicht vertiefen, zumal ich nur bei Tests im Backend-Bereich involviert war. Aber zumindest schien es einige Probleme mit den Libraries zu geben, die für das GUI-Testen benutzt werden mussten. Aber da das über ein Jahr zurück liegt wird es sicherlich Fortschritte in dem Bereich gegeben haben.

In diesem Sinne “happy testing and roboting” … :-)

Da dieses Problem nicht auftritt wenn die Applikation aus Eclipse heraus gestartet wird, habe ich im Terminal ein wenig mit ps gespielt und herausgefunden, dass Eclipse per default die folgenden Java Option setzt -XstartOnFirstThread. Startet man das Runnable JAR direkt (per Doppelklick) fehlt diese Option.

Dieses Problem wird auch im SWT FAQ behandelt, aber das habe ich erst hinterher gefunden ;):

Q: On Mac Carbon, how do I run an SWT application from the command line?
A: If you run a Java application that uses Carbon via JNI, the application is not registered with the OS as a ‘normal’ UI application. As a consequence, it has no entry in the dock and it cannot be activated. AWT (or Swing) based applications don’t have this problem because they seem to use undocumented SPI to register themselves.
To work around this problem you’ll have to pass the -XstartOnFirstThread option to the java executable as follows:

java -XstartOnFirstThread -cp swt.jar:. ControlExample

If you want to run a bundled application, take a look at this article.

Zum Glück führt das FAQ dann auch direkt zu diesem Artikel, der beschreibt wie man aus einem Runnable JAR ein Mac OS Bundle machen kann. Das ist genau die Information, die mir noch gefehlt hat und das werde ich natürlich vorm Release von iPlode noch ausprobieren und dann berichten; ich hoffe vielmehr man kann das Ergebnis dann hier bewundern :).

Wenn man sich von der etwas überfrachteten Webseite nicht abschrecken lässt und auch nicht von dem nötigen Account für den Download bekommt man ein auf Eclipse basiertes UML-Tool, welches einen sehr guten Eindruck macht. Für nicht-kommerzielle Projekte gibt es eine Community-Version mit eingeschränkter Funktionalität. Die folgende Übersicht zeigt alle möglichen Editionen und Preise. Einen Feature-Vergleich der verschiedenen Editionen findet man hier.

Um ein paar Gedanken (UML-technisch) zu ordnen oder auch einfach nur zum Ausprobieren ist Visual Paradigm schon in der Community-Version gut zu gebrauchen. Wer täglich mit Eclipse arbeitet wird den Einstieg als noch einfacher (intuitiver) empfinden.

Leider finden sich die richtig geilen Features, die auch einen eher agilen Entwicklungsansatz unterstützen würden, erst ab der Professional Edition. Diese ist mit knapp $840 dann doch etwas teuer für den privaten Gebrauch. Ab dieser Version gibt es dann das “Java Round-trip” Feature. Damit lässt sich sowohl Java-Code aus dem Model generieren, als auch das Model aus dem Java-Code. Somit würde sich zumindest der aktuelle Stand dokumentieren lassen. Manchmal ist ja dann der Blick auf ein UML-Diagramm schon hilfreich, um die Klassenstruktur besser zu verstehen. Wenn im neuen Jahr ein wenig mehr Zeit am Stück ist, werde ich dieses Features mit Hilfe einer Evaluierungs-Lizenz nochmal näher unter die Lupe nehmen.

Mein Problem ist eher, dass ich im Urlaub nicht immer Online sein kann und deswegen eine Offline-Version der entsprechenden SWT API-Documentation gesucht habe. Vielleicht habe ich falsch gesucht, aber ich bin nicht fündig geworden (google war hier mal nicht mein Freund ;)). Und auch die Version, die Eclipse bereit stellt beinhaltet keine Sourcen und daher auch kein JavaDoc.

Die Suche nach den passenden SWT-Sourcen auf der Eclipse Homepage gestaltet sich dabei etwas schwieriger, aber am Ende bin ich dann doch fündig geworden (passenden Download-Link am Ende der Seite auswählen). Dieses Package beinhaltet die kompletten Sourcen in einem File src.zip. Von hier an habe ich einen recht klassischen Weg gewählt, um an die Offline-Version der API-Doku zu kommen. Nach dem Auspacken des src.zip Files findet man unter org/eclipse/swt alle Quelldateien.

Nach ein wenig Kramen im Gedächtnis und Ausprobieren war das passende javadoc-Kommando zusammengebaut. Vorher noch ein javadoc-Verzeichnis anlegen und es kann los gehen. Das folgende Kommando läuft so unter Unix (in diesem Fall Mac OS), sollte aber mit leichten Anpassungen auch problemlos unter Windows laufen. Die Pfade müssen natürlich in jedem Fall angepasst werden.

javadoc -d /Users/thomasjaspers/Java/Lib/swt-3.4.1-carbon-macosx/javadoc -sourcepath /Users/thomasjaspers/Java/Lib/swt-3.4.1-carbon-macosx/src/ org.eclipse.swt.accessibility org.eclipse.swt.awt org.eclipse.swt.browser org.eclipse.swt.custom org.eclipse.swt.dnd org.eclipse.swt.events org.eclipse.swt.graphics org.eclipse.swt.internal org.eclipse.swt.layout org.eclipse.swt.opengl org.eclipse.swt.printing org.eclipse.swt.program org.eclipse.swt.widgets org.eclipse.swt

Danach ist die API-Documentation im javadoc-Verzeichnis verfügbar und kann mit einem Klick auf index.html lokal gestartet werden. Das Ganze ist zumindest ein Weg an die passenden Dokumentation zu kommen. Für Tips wenn es noch einfachere Möglichkeiten gibt (z.B. direkt in Eclipse) bin ich auf jeden Fall dankbar. Aber für den Urlaub reicht erstmal die LowTech Lösung :).