Ein Debugger für das Robot Framework (beinahe)

In meinem letzten Blog-Eintrag habe ich versprochen, über den „robotframework debuger [sic!]“ (im Folgenden einfach „Debugger“ oder kurz „RDB“) zu schreiben. War das vielleicht voreilig? Die Download-Seite des Projekts auf Google Code sagt „prototype“. Hätte mich das abschrecken sollen? Das Repository zeigt nach dem initialen Commit seit mehr als zwei Jahren keine weitere Aktivität. Hätte mir das eine Warnung sein sollen?

Nein, warum denn auch?

Willkommen zu einer Reise in die Open-Source-Welt der Kategorie „not quite finished yet“. Erfahren Sie, warum RDB das Werkzeug ist, das Sie bei Robot schon immer vermisst haben, und warum es Ihnen trotzdem nicht helfen wird… 😉

Startschwierigkeiten

Der Anfang ist schon mal vielversprechend. Es gibt neben dem Sourcecode auch ein Distributionspaket und genau eine Seite Dokumentation. Das Setup funktioniert nicht, weil im Distributionspaket eine Datei fehlt. Zum Glück ist der Quellcode vollständig und eine Installation aus dem Source-Verzeichnis heraus möglich.

RDB ist als Listener implementiert und realisiert damit den Ansatz, den ich bereits vorgestellt habe . Ein vorsichtiger Start mit „pybot --listener rdb.Listener EinfacherTest.txt“ führt aber unmittelbar zur Vollbremsung: pybot bricht mit einem Import-Fehler ab, weil von RDB verwendete Robot-Module nicht gefunden werden.

Eine Suche im Repository führt schnell zu zwei Erkenntnissen:

1. Das letzte stabile Release von Robot, das den Anforderungen von RDB genügt, müsste Robot 2.5 gewesen sein.
2. Die benötigten Robot-Module sind inzwischen im Rahmen des Refactoring endgültig gelöscht worden.

Damit fällt ein schneller Fix aus. Stattdessen hole ich mir das Release 2.5 aus dem Robot-Repository, um damit RDB ausprobieren zu können.

Der erste Eindruck überrascht: Ohne Angabe eines Breakpoints läuft der Test trotz Debugger einfach durch. Hier muss man gegenüber dem Verhalten anderer Debugger umdenken. Mit einem Breakpoint („pybot --listener rdb.Listener:Log EinfacherTest.txt“ stellt einen Breakpoint auf das Keyword „Log“ ein) gestartet, läuft der Test bis zum Breakpoint und wird dort angehalten. Auf der Kommandozeile gibt RDB außerdem die URL aus, über die die Web-GUI des Debuggers erreichbar ist.

Oberfläche & Funktionen

Die Verwendung einer Web-GUI ist ein einfacher, aber genialer Schachzug, da somit die Beeinflussung des „System under Test“ durch die Bedienung des Debugger ausgeschlossen wird. Keine ungewollter Fokuswechsel mehr beim GUI-Test!

Die GUI ist einfach und übersichtlich. Links oben werden Informationen zum aktuellen Keyword dargestellt. Dabei wird der Keyword-Stack angezeigt, d.h. bei benutzerdefinierten Schlüsselwörtern werden die gesamte Hierarchie angezeigt. Rechts oben können weitere Breakpoints gesetzt werden und bestehende (de-)aktiviert werden. Mittig rechts werden die aktuell gesetzten Variablen mit ihren Werten dargestellt. Werte können geändert und neue Variablen angelegt werden. Außerdem existiert ein Eingabefeld, um Robot-Keywords ad hoc ausführen zu können. Mittig links wird der Status des Tests und des Debuggers angezeigt. Am unteren Rand werden die Argumente des Listener dargestellt, womit man z.B. die Argumente des zur Ausführung anstehenden Keyword sehen kann.

Oberhalb den Anzeigen des Debuggers werden Buttons für die Ablaufsteuerung anzeigt. Hier bietet der Debugger fast alles:

• „Run“: Test ausführen bis zum nächsten Breakpoint oder zum Ende der Suite
• „Go into“: Keyword ausführen; bei benutzerdefinierten Keywords verzweige in die Definition (im Einzelschrittmodus)
• „Go over“: Keyword ausführen; bei benutzerdefinierten Keywords verzweige nicht in die Definition
• „Go return“: Test ausführen bis zum nächsten [Return], Breakpoint oder Ende des Tests
• „Pause“: Pausiert einen laufenden Test, ohne Breakpoint
• „Refresh“: Aktualisiert die Anzeige

Neben Informationen zu den Keywords werden auch aktuell verwendete Variablen mit Inhalt angezeigt. Neue Variablen können angelegt und Variablenwerte geändert werden.

Schlaglöcher

Allerdings gibt es auch einiges, was nicht sauber funktioniert. Die Web-GUI arbeitet mit Firefox (v13) und Internet Explorer (v9), wobei aber die ersten paar Klicks verschluckt werden. Ein Bedienung mit Chrome (v20) scheint nicht möglich – die GUI wird zwar korrekt dargestellt, aber Klicks zeigen keine Wirkung.

Des Weiteren verarbeitet die GUI eingegebene Leerzeichen falsch: sie werden durch Plus-Zeichen ersetzt. Dadurch können Funktionen mit manuellen Eingaben (Setzen neuer Breakpoints, Ändern von Variablenwerte, Ausführen von Keywords) de-facto nicht genutzt werden.

Wunschzettel

Welche Funktionen würde man sich denn von einem Debugger noch wünschen?

• Quelltestansicht: Anzeige der vollständigen Test-Case-Dateien; Navigation innerhalb der Test-Suite
• Interaktive Breakpoint-Verwaltung
• Testcases als Breakpoint verwenden (es können wirklich nur Keywords als Breakpoints verwendet werden)
• Skip: Einen Testschritt auslassen
• Testcode ändern
• Tests an einem beliebigen Punkt vorsetzen, also z.B. auch einen „Rückschritt“ ausführen
• …

Fazit: Leider nicht einsetzbar

Wie soll man das ganze nun beurteilen? Es handelt sich um einen echten Prototypen. Er zeigt das Konzept und viele gute Funktionen. Er stiftet unmittelbar Nutzen. Auf der anderen Seite fehlen Funktionen oder sind fehlerhaft, auch solche, die für einen Alltagseinsatz wichtig wären. Entscheidend ist aber die fehlende Weiterentwicklung. Da der Debugger nie auf den Stand der aktuellen Robot-Releases angehoben wurde, ist er nicht einsatzbar.

Eine Anfrage beim Project Owner zur Zukunft des Projekts blieb bis zum Zeitpunkt des Schreibens dieser Zeilen leider unbeantwortet.

Das schreit doch nach einer Fork, oder? 😀

PS: Mich würde interessieren, was Sie überhaupt von der Idee eines interaktiven Debuggers für Robot halten. Wie debuggen Sie Ihre Tests? Oder reicht konsequentes Logging? Kommentare erwünscht!