Dieser Abschnitt erläutert die technischen Details der Integration von Jython und Groovy in QF-Test. Er enthält eine vollständige Referenz des API, das Jython und Groovy Skripten zur Interaktion mit QF-Test zur Verfügung steht. Eine weniger technische Einführung finden Sie in Kapitel 13.

Der Loadpath für Python/Jython Module (sys.path) wird aus verschiedenen Teilen in folgender Reihenfolge zusammengesetzt:

• Das Verzeichnis qftest/jython
• Das Verzeichnis qftest/qftest-3.4.7/jython/Lib
• Verzeichnisse, die in der System Property python.path definiert sind

Zusätzlich wird dem Pfad während der Ausführung eines 'Server Skript' oder 'SUT Skript' Knotens das Verzeichnis der Testsuite vorangestellt.

Das Verzeichnis qftest/qftest-3.4.7/jython/Lib enthält Jython-interne Module, die gesamte Python Bibliothek, sowie folgende von Quality First Software GmbH bereitgestellte Module: qfcommon.py, qftest.py und qfclient.py. Sie sollten diese Dateien nicht modifizieren, da sie sich jederzeit ändern können und auf die jeweilige Version von QF-Test zugeschnitten sind.

Ihre eigenen gemeinsam benutzten Module sollten Sie im Verzeichnis qftest/jython ablegen. Dieses wird bei einem Update von QF-Test nicht angetastet. Module, die speziell auf eine Testsuite abgestimmt sind, können auch im Verzeichnis der Testsuite stehen. Alle Module müssen die Endung .py haben.

Um weitere Verzeichnisse zum Loadpath hinzuzufügen, können Sie die System Property python.path nutzen.

Mittels Jython und Groovy kann auch auf Java Klassen und Methoden zugegriffen werden, die nichts speziell mit QF-Test zu tun haben, indem diese Klassen einfach importiert werden, z.B.:

from java.util import Date
from java.text import SimpleDateFormat
print SimpleDateFormat("yyyy-MM-dd").format(Date())

Zugriff gibt es auf alle Klassen, die sich beim Start von QF-Test bzw. des SUT auf dem CLASSPATH befinden, alle Klassen des Standard Java API, sowie QF-Test's eigene Klassen. Für das SUT hängt vieles vom verwendeten ClassLoader Konzept ab. Insbesondere bei WebStart und Eclipse/RCP ist es schwierig, Klassen des SUT direkt zu importieren.

Zusätzlich gibt es Plugin Verzeichnisse, in die Sie einfach eine jar Datei stellen können, um sie in Skripten verfügbar zu machen. Standardmäßig heißt das primäre Plugin Verzeichnis plugin und steht im Wurzelverzeichnis von QF-Test, qftest. Dies kann über das Kommandozeilenargument -plugindir <Verzeichnis> geändert werden.

Jar Dateien im primären Plugin Verzeichnis stehen sowohl 'Server Skript', als auch 'SUT Skript' Knoten zur Verfügung. Um eine jar Datei ausschließlich für 'Server Skripte' oder ausschließlich für 'SUT Skripte' bereitzustellen, stellen Sie diese stattdessen in das zugehörige Unterverzeichnis namens qftest bzw. sut.

Jython verwaltet einen Cache mit Package Informationen, um schnell auf Java Klassen zugreifen zu können. Dieser liegt normalerweise im Verzeichnis qftest/jython/cachedir. Falls dieses Verzeichnis nicht beschreibbar ist, wird stattdessen .qftest/jython-cachedir im Heimatverzeichnis des Anwenders verwendet. Sie können das Verzeichnis für den Cache auch mit der System Property python.cachedir selbst definieren.

Wenn Sie QF-Test nach der Installation starten, werden Sie vielleicht einige Meldungen der folgenden Form sehen:

*sys-package-mgr*: processing...

Später sollten diese Meldungen nur dann auftauchen, wenn Sie ein jar Archiv auf dem CLASSPATH geändert oder neue hinzugefügt haben. Es kann vorkommen, dass Jython einen Schluckauf bekommt und für manche jar Archive den Cache jedes mal neu erzeugt. In diesem Fall können Sie einfach das gesamte Verzeichnis qftest/jython/cachedir oder .qftest/jython-cachedir löschen, womit das Problem beseitigt sein sollte.

Beim Start von QF-Test und des SUT wird ein Jython Interpreter erzeugt und in die Applikation eingebettet. Für QF-Test wird dabei das Modul qftest geladen, für das SUT das Modul qfclient. Beide basieren auf dem Modul qfcommon, das den gemeinsamen Code enthält. Diese Module werden benötigt, um die Schnittstelle zum Runcontext und den globalen Namespace bereitzustellen.

Anschließend wird der Loadpath sys.path nach Ihren persönlichen Modulen für die Initialisierung durchsucht. Für QF-Test wird die Datei qfserver.py geladen, für das SUT die Datei qfsut.py. In beiden fällen werden die Dateien mittels execfile ausgeführt, womit der Inhalt der Dateien direkt im globalen Namespace landet. Dies ist für Initialisierungsdateien von Vorteil, da alle Module, die von diesen importiert werden, direkt für 'Server Skript' und 'SUT Skript' Knoten zur Verfügung stehen. Bedenken Sie bei Ihren Initialisierungsdateien, dass zu diesem Zeitpunkt noch kein Runcontext und kein Testsuite-spezifisches Verzeichnis in sys.path zur Verfügung stehen.

Die Umgebung in der 'Server Skripte' oder 'SUT Skripte' ausgeführt werden, wird durch den globalen und lokalen Namespace bestimmt, die während der Ausführung definiert sind. Namespaces sind Jython Dictionaries, welche die Bindungen für die globalen und lokalen Variablen beinhalten.

Der globale Namespace wird von allen Skripten, die in demselben Jython Interpreter laufen, gemeinsam genutzt. Er enthält zunächst nur die Klassen TestException und UserException, das Modul qftest bzw. qfclient für QF-Test bzw. das SUT, und alles, was in qfserver.py bzw. qfsut.py definiert und importiert wurde. Wenn Sie in einem Skript eine Variable mit Hilfe des global Statements als global deklarieren und ihr einen Wert zuweisen, wird diese in den globalen Namespace aufgenommen und steht damit für weitere Skripte zur Verfügung. Zusätzlich nimmt QF-Test automatisch alle Module in den globalen Namespace auf, die während der Ausführung eines Skripts importiert werden.

Der lokale Namespace wird für jedes Skript neu erstellt. Beim Aufruf des Skripts enthält er das Objekt rc, die Schnittstelle zu QF-Tests Runcontext, sowie true und false mit den Werten 1 und 0 zur besseren Integration mit QF-Test.

Für den Zugriff auf und das Setzen von Variablen in einem fremden Jython Interpreter, stehen die Runcontext Methoden fromServer, fromSUT, toServer und toSUT zur Verfügung.

Das Runcontext Objekt rc ist die Schnittstelle zum Ausführungszustand des laufenden Tests in QF-Test. Die Verwendung einer zusätzlichen Schicht erlaubt Änderungen an der Implementierung von QF-Test, ohne die Schnittstelle für Skripte zu gefährden.

Es folgt eine alphabetische Aufstellung aller Methoden des Runcontext Objekts rc. Die verwendete Syntax ist ein Gemisch aus Java und Python. Python unterstützt zwar selbst keine statische Typisierung, die Parameter werden jedoch an Java weitergereicht, so dass falsche Typen Exceptions auslösen können. Folgt einem Parameter ein '=' Zeichen und ein Wert, ist dies der Defaultwert des Parameters und eine Angabe beim Aufruf ist optional.

Hinweis Die Groovy Syntax für Keyword-Parameter unterscheidet sich von Jython. Groovy verwendet ':' statt '='. Dies ist besonders tückisch, weil z.B. rc.logMessage("bla", report=true) durchaus legaler Groovy Code ist, der allerdings nicht den gewünschten Effekt hat. Das '=' ist hierbei eine Zuweisung mit dem Wert true, der dann ganz einfach als zweiter Parameter übergeben wird, so dass der Aufruf äquivalent ist zu rc.logMessage("bla", true). Hierbei wird true aber für dontcompactify statt report verwendet. Die korrekte Version für Groovy lautet rc.logMessage("bla", report:true).

In manchen Fällen ist kein Runcontext verfügbar, insbesondere wenn eines der in den folgenden Abschnitten beschiebenen Interfaces zur Erweiterung von QF-Test implementiert wird. Das Modul qf ermöglicht Logging auch in diesen Fällen und bietet weitere allgemein hilfreiche Methoden, die keinen Runcontext benötigen. Es folgt eine alphabetische Aufstellung aller Methoden des qf Moduls. Sofern nicht anders angegeben sind die Methoden in Jython und Groovy sowohl für 'Server Skript' als auch 'SUT Skript' Knoten verfügbar.

Hinweis Die Groovy Syntax für Keyword-Parameter unterscheidet sich von Jython. Groovy verwendet ':' statt '='. Dies ist besonders tückisch, weil z.B. qf.logMessage("bla", report=true) durchaus legaler Groovy Code ist, der allerdings nicht den gewünschten Effekt hat. Das '=' ist hierbei eine Zuweisung mit dem Wert true, der dann ganz einfach als zweiter Parameter übergeben wird, so dass der Aufruf äquivalent ist zu qf.logMessage("bla", true). Hierbei wird true aber für dontcompactify statt report verwendet. Die korrekte Version für Groovy lautet qf.logMessage("bla", report:true).

Die Image API stellt Klassen und Interfaces bereit, um Bildschirmabbilder zu erstellen, Bilder in Dateien zu speichern oder zu aus Dateien zu laden. Es können auch eigene Bildvergleiche durchgeführt werden.

Um Bildschirmabbilder zu erstellen, können Sie die Jython Klasse ImageWrapper aus dem Modul imagewrapper.py verwenden. Dieses Modul wird mit dem QF-Test Installationspaket mitgeliefert.

Hier sehen Sie ein kleines Jython Beispiel, um die Verwendung der Image API darzustellen:

from imagewrapper import ImageWrapper

#create ImageWrapper instance
iw = ImageWrapper(rc)

#take screenshot of the whole screen
currentScreenshot = iw.grabScreenshot()

#save screenshot to a file
iw.savePng("/tmp/screenshot.png", currentScreenshot)

Das gleiche mit Groovy:

import de.qfs.ImageWrapper

def iw = new ImageWrapper()
def currentScreenshot = iw.grabScreenshot()
iw.savePng("/tmp/screenshot.png", currentScreenshot)

Es folgt eine alphabetische Aufstellung aller Methoden der ImageWrapper Klasse. Die verwendete Syntax ist ein Gemisch aus Java und Python. Python unterstützt zwar selbst keine statische Typisierung, die Parameter werden jedoch an Java weitergereicht, so dass falsche Typen Exceptions auslösen können. Folgt einem Parameter ein '=' Zeichen und ein Wert, ist dies der Defaultwert des Parameters und eine Angabe beim Aufruf ist optional.

Alle QF-Test Exceptions, die in Kapitel 31 aufgeführt sind, werden in Jython automatisch importiert und stehen in Skripts für try/except zur Verfügung, z.B.:

try:
    com = rc.getComponent("someId")
except ComponentNotFoundException:
    ...

In Groovy müssen die Exceptions erst importiert werden:

import de.qfs.apps.qftest.shared.exceptions.ComponentNotFoundException

try {
    com = rc.getComponent("someId")
} catch (ComponentNotFoundException) {
    ...
}

Explizit sollten aus Skriptcode nur die folgenden Exceptions geworfen werden (mit raise bzw. throw new):

• UserException("Irgendeine Meldung...") dient als Signal für eine aussergewöhnliche Fehlersituation.
• BreakException() oder raise BreakException("loopId") kann dazu verwendet werden, um aus einer 'Schleife' oder einem 'While' Knoten auszubrechen. Die Variante ohne Parameter unterbricht die innerste Schleife, mit der Id als Parameter kann gezielt eine bestimmte Schleife abgebrochen werden.
• ReturnException() oder ReturnException("value") kann - mit oder ohne Rückgabewert - zur Rückkehr aus einer 'Prozedur' verwendet werden, analog zu einem 'Return' Knoten.

Wenn Sie mit Jython Modulen arbeiten, müssen Sie nach der Änderung eines Moduls QF-Test oder das SUT nicht neu starten sondern können mit Hilfe von reload(<Modulname>) das Modul erneut laden.

Das Debuggen von Skripten in einem eingebetteten Interpreter kann etwas mühsam sein. Um es zu vereinfachen bietet QF-Test Terminalfenster für die Kommunikation mit allen Jython Interpretern an. Diese Terminals sind über das »Clients« Menü oder über »Extras«-»Jython Terminal...« zugänglich.

Alternativ können Sie eine Netzwerkverbindung zu einem Jython Interpreter aufbauen, um eine interaktive Kommandozeile zu erhalten. Dies funktioniert sowohl mit QF-Test als auch mit dem SUT. Um dieses Feature zu aktivieren, müssen Sie QF-Test mit dem Kommandozeilenargument -jythonport <Nummer> starten, mit dem Sie die Portnummer für den Zugang zum Jython Interpreter angeben. Für das SUT definieren Sie diese mit Hilfe eines 'Parameters' in der "Extra" Tabelle des 'Java SUT Client starten' oder 'SUT Client starten' Knotens. Setzen Sie dieses auf -jythonport=<Portnummer>. Anschließend können Sie sich mittels

telnet localhost <Portnummer>

mit dem entsprechenden Jython Interpreter verbinden. Dank Jythons Möglichkeiten zum Zugriff auf das gesamte Java API erhalten Sie auf diesem Weg sogar eine ganz allgemeine interaktive Debuggingschnittstelle zu Ihrer Applikation.

Letzte Änderung: 23.04.2012 Copyright © 1999-2012 Quality First Software GmbH