Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

|
//

Das Listener Interface des Robot Framework

19.6.2012 | 7 Minuten Lesezeit

Dem Robot auf die Schrauben geschaut…

Früher oder später kommt sie immer – die Frage nach dem Debugging von Robot. Ob bei einer Vorstellung des Frameworks oder bei einem Training, irgendwann heißt es immer: „Und wie kann man das debuggen?“

Nun könnte man einwenden, eine automatisierte Testsuite sollte man gar nicht debuggen (müssen), schließlich ergibt sich aus den feingranularen Tests der Fehlergrund ganz von selbst. Aber das ist natürlich Illusion. Jeder kennt die Tests, die nur deshalb fehlschlagen, weil ein unerwartetes modales Pop-Up den Fokuswechsel zu einem anderen Fenster nicht zulässt oder weil ein benötigtes Oberflächenelement noch nicht angezeigt wird. Dann wünscht man sich, den Test anhalten zu können, um einfach mal nachzuschauen, was da gerade schief geht.

Und das geht auch mit dem Robot Framework. Die magischen Worte lauten Listener Interface.

Das Robot Framework stellt ein Interface bereit, um als Klassen oder Module implementierte Listener einzubinden. Diese Listener werden beim Start des Frameworks registriert und bekommen dann Nachrichten beim Auftreten einer ganzen Liste von wichtigen Ereignissen. Der Aufruf eines Listeners erfolgt synchron und blockiert die Ausführung der Test-Suite.

Listener können in Java oder in Python implementiert werden. Eine Übersicht aller Ereignisse bzw. aller zulässigen Hooks findet sich im Robot-Userguide. Zum Glück müssen nur die Methoden / Funktionen implementiert werden, die man auch wirklich verwenden möchte.

Implementierte Listener müssen zur Laufzeit im Pfad des Robot Framework liegen, also entweder im Modul-Suchpfad oder durch Verwendung einer Pfadangabe (relativ, absolut) bei der Registrierung.

Zur Registrierung muss ein Listener beim Start des Robot Framework mit der Kommandozeilenoption --listener übergeben werden. Dabei können auch Argumente an den Listener übergeben werden. Dazu später mehr.

Ein einfacher Listener

Beginnen wir mit einem konkreten Beispiel: Wir möchten, dass der Testlauf vor Beginn eines neuen Testfalls gestoppt wird und erst nach dem Klick auf einen Button in einem Dialogfenster weiterläuft.

Hier zunächst unsere sehr komplexe und total realistische Test-Suite:

Dateiname: EinfacherTest.txt

1*** Test Case ***
2Einfacher Testfall
3  [Documentation]  Ein einfacher Testfall als Listener-Demo
4  ${test_var}=  Set Variable  OK
5  Should Be Equal  ${test_var}  OK

Nun brauchen wir einen Listener, der zu Beginn eines neuen Testfalls einen Dialog öffnet und auf einen Klick wartet. Dazu bauen wir uns ein Python-Modul, das die Funktion start_test implementiert. start_test hat zwei Parameter, den Namen des Testfalls als String und die Attribute des Testfalls als Dictionary. Welche Attribute in dem Dictionary übergeben werden, steht im Userguide.

Dateiname: BitteWarten.py

1import tkMessageBox
2from Tkinter import Tk
3 
4ROBOT_LISTENER_API_VERSION = 2
5 
6def start_test(name, attributes):
7    Tk().withdraw() # Root-Fenster entfernen
8    tkMessageBox.showinfo("Please click 'OK'...",
9                          "Test Case Name: " + name)

Nun können wir den Listener beim Start von Robot übergeben und uns das Ergebnis anschauen.

1pybot --listener BitteWarten EinfacherTest.txt

Als Ergebnis sollte folgender Dialog dargestellt werden:

Listener mit Argumenten

Nun ist dieser Ansatz spätestens dann viel zu einfach, wenn man mehr als einen Testfall in der Suite hat. Keiner möchte 20mal „Ok“ klicken, um bis zum gewünschten Testfall vorzudringen. Hier helfen Listener weiter, die man mittels Argumenten konfiguriert.

In Python muss man die Implementierung von Modul auf Klasse umstellen, wenn man Listener mit Argumenten verwenden möchte, da die Argumente im Konstruktor übergeben werden. Also muss die Listener-Klasse eine __init__-Methode implemenentieren, die alle erwarteten Parameter in der richtigen Reihenfolge entgegennimmt. In unserem Fall benötigen wir nur einen Parameter, den Testnamen.

Anmerkung: Da Argumente optional sind, sollten die Parameter der __init__-Methode immer sinnvolle Default-Werte haben.

Dateiname: BitteWartenMitArg.py

1import tkMessageBox
2from Tkinter import Tk
3 
4class BitteWartenMitArg():
5    ROBOT_LISTENER_API_VERSION = 2
6 
7    def __init__(self, test_name = ''):
8        self.test_name = test_name
9 
10    def start_test(self, name, attributes):
11        if (name == self.test_name) or ('' == self.test_name):
12            Tk().withdraw() # Root-Fenster entfernen
13            tkMessageBox.showinfo("Please click 'OK'...",
14                                  "About to start test '%s'" % name)

Dieser Listener wartet vor dem Start des angegebenen Testfalls bzw. bei allen Testfällen, falls kein Testfallname übergeben wurde.

Um die Funktionsweise wirklich zu prüfen, brauchen wir natürlich einen weiteren Testfall für unsere Test-Suite…

Dateiname: ZweiTests.txt

1*** Test Cases ***
2Einfacher Testfall
3  [Documentation]  Ein einfacher Testfall als Listener-Demo
4  ${test_var}=  Set Variable  OK
5  Should Be Equal  ${test_var}  OK
6 
7Weiterer Test
8  [Documentation]  Don't be evil...
9  Log  Nur keine Panik!

Bei der Registrierung des Listeners werden Argumente durch Doppelpunkte getrennt angegeben. Weitere Argumente werden mit zusätzlichen Doppelpunkten angehängt.

1pybot --listener BitteWartenMitArg:"Einfacher Testfall" ZweiTests.txt

Wenn alles richtig läuft, wird die Testausführung nur vor dem ersten Testfall angehalten, aber nicht vor dem zweiten Testfall.

Hinweis: (Doppelte) Anführungszeichen werden hier nur verwendet, weil das Argument ein Leerzeichen enthält. Grundsätzlich brauchen Argumente nicht in Anführungszeichen gesetzt zu werden.

Jeder sollte auch mal ausprobieren was passiert, wenn man das Argument weglässt.

Variablen mittels Listener anzeigen

Aber Listener können auch noch mehr. So können sie z.B. auch die Test-Libraries verwenden. Über die „BuiltIn“-Library können somit Variablen ausgelesen werden.

Dateiname: VariableAnzeigen.py

1import tkMessageBox
2from Tkinter import Tk
3from robot.libraries.BuiltIn import BuiltIn
4 
5ROBOT_LISTENER_API_VERSION = 2
6 
7def end_test(name, attributes):
8    Tk().withdraw() # Root-Fenster entfernen
9    tkMessageBox.showinfo("Please click 'OK'...",
10                          "test_var = '%s'" % BuiltIn().get_variables()['${test_var}'])

Die Ausführung mit…

1pybot --listener VariableAnzeigen EinfacherTest.txt

… sollte folgende Ansicht ergeben:

Und wie geht’s jetzt weiter?

Diese Beispiele sollten zeigen, dass man mit Listenern im Robot Framework einiges anstellen kann. Mit Sicherheit hat sich jemand bereits vor vier Absätzen gedacht, „Hey, damit kann man ja bestimmt ganz einfach einen echten Debugger bauen!“ Bevor sich jetzt jeder vor die Konsole klemmt und ein neues Repository in GitHub anlegt: Gibt’s schon und zwar hier . Über die Verwendung dieses Remote-Debuggers für Robot werden ich demnächst ein paar Zeilen schreiben.

Exkurs „API-Version“

Vielleicht ist bereits die Variable ROBOT_LISTENER_API_VERSION in meinen Beispielen aufgefallen. Durch sie wird festgelegt, welche Version der Listener-API der Listener verwenden möchte. Die API ist mit Robot Framework Version 2.1 heftig überarbeitet worden. Um die Kompatibilität alter Listener zu gewährleisten, wurde die Variable ROBOT_LISTENER_API_VERSION eingeführt. Ist sie auf den Wert 2 gesetzt, so wird die neue Version der API verwendet. Default-Verhalten beim Fehlen dieser Variable ist die Verwendung der alten API-Version. Es gibt keinen Grund, die alte API-Version bei neuem Code noch zu verwenden (man müsste außerden im Repository erstmal eine alte Userguide-Version suchen, die die API-Version 1 beschreibt…), aber dieses Default-Verhalten kann zu Verwirrung führen, gerade wenn man nicht täglich mit Python arbeitet oder wieder einmal neuen Code mittels Copy & Paste „schreibt“…

Vergisst man dabei nämlich die Angabe der API-Version oder stellt sie aus Versehen außerhalb der Klassendefinition, so wird der Listener mit der alten API angesprochen und man bekommt die tollsten Fehlermeldungen. Also, wenn man Fehlermeldungen im Stile von

[ ERROR ] Calling listener method 'start_test' of listener 'BitteWartenMitArg' failed: TypeError: start_test() takes exactly 3 arguments (4 given)

bekommt, einfach mal nachschauen, ob ROBOT_LISTENER_API_VERSION vorhanden ist, den richtigen Wert 2 hat und auch an der richtigen Stelle steht. In diesem Fall hatte ich die Variable vor class BitteWartenMitArg(): verschoben und somit aus der Klassendefinition entfernt – ein typischer Copy-Paste-Fehler.

Exkurs „Java“

Ganz zu Anfang habe ich geschrieben, dass Listener auch in Java geschrieben werden können. Aber wie sieht das genau aus und was ist dabei zu beachten?

Hier zunächst die drei Listener, in Java umgesetzt…

Dateiname: BitteWartenJ.java

1import java.util.Map;
2import javax.swing.JOptionPane;
3 
4public class BitteWartenJ {
5    public static final int ROBOT_LISTENER_API_VERSION = 2;
6 
7    public void startTest(String name, Map attributes) {
8        JOptionPane.showMessageDialog(null, "Test name: " + name);
9    }
10}

Dateiname: BitteWartenMitArgJ.java

1import java.util.Map;
2import javax.swing.JOptionPane;
3 
4public class BitteWartenMitArgJ {
5    public static final int ROBOT_LISTENER_API_VERSION = 2;
6 
7    private String testName;
8 
9    // Leerer Konstruktor, falls das Argument weggelassen wird...
10    public BitteWartenMitArgJ() {
11        this.testName = "";
12    }
13 
14    // Konstruktor, der das Argument entgegennimmt...
15    public BitteWartenMitArgJ(String testName) {
16        this.testName = testName;
17    }
18 
19    public void startTest(String name, Map attributes) {
20        if (name.equals(testName) || ("".equals(testName)))
21            JOptionPane.showMessageDialog(null, "Test name: " + name);
22    }
23}

Dateiname: VariableAnzeigenJ.java

1import java.util.Map;
2import javax.swing.JOptionPane;
3 
4import javax.script.ScriptEngine;
5import javax.script.ScriptEngineManager;
6import javax.script.ScriptException;
7 
8public class VariableAnzeigenJ {
9    public static final int ROBOT_LISTENER_API_VERSION = 2;
10 
11    public void endTest(String name, Map attributes) throws ScriptException {
12        ScriptEngine engine = new ScriptEngineManager().getEngineByName("python");
13        engine.eval("from robot.libraries.BuiltIn import BuiltIn");
14        engine.eval("v = BuiltIn().get_variables()['${test_var}']");
15        Object testVar = engine.get("v");
16        JOptionPane.showMessageDialog(null, "test_var = " + testVar);
17    }
18}

Grundsätzlich kann man erstmal feststellen: Es geht tatsächlich! Allerdings sind die Java-basierten Listener bei dem geringen funktionalen Umfang dieser Beispiele doch recht umständlich in der Handhabung.

Folgende Punkte verdienen Beachtung:

  • Natürlich muss Robot in diesem Fall mit Jython (jybot) gestartet werden.
  • Extensions werden bei der Registierung eines Listener ignoriert. Bie der gleichzeitigen Verwendung von Python und Java kann es daher passieren, dass man versehentlich Modul- / Klassen-Namen doppelt verwendet. Robot lädt die Python-Variante.
  • Im Gegensatz zu Python-Code muss der Java-Code vorher kompiliert werden.
  • Argumente sind optional! Daher braucht man auch Konstruktoren, bei denen Argumente „fehlen“ (siehe mittleres Beispiel).
  • Der Zugriff auf Python-basierte Libraries ist etwas umständlicher (siehe letztes Beispiel).
|

Beitrag teilen

Gefällt mir

0

//

Weitere Artikel in diesem Themenbereich

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.