Die Robot Framework Remote Library-Schnittstelle: Verwendung der Remote Database Library zur Verbindung mit IBM DB2

Im Nachgang zu meinem Robot Framework-Workshop auf der Xebia 2015 TestWorks Conf erhielt ich mehrere E-Mails von Teilnehmern des Workshops. Sie stellten Fragen und schilderten (kleinere und größere) Probleme im Zusammenhang mit verschiedenen Aspekten ihrer Testautomatisierungsbemühungen mit dem Robot Framework. Einige dieser Fragen und Probleme sind identisch mit denen, die mir als Berater in der Praxis begegnen. Da die betreffenden Themen also auch für ein breiteres Publikum von Interesse sein könnten, habe ich beschlossen, ihnen eine Reihe von Blogbeiträgen zu widmen. Besser (sehr) spät als nie, oder? Der erste dieser Beiträge zeigt Ihnen, wie Sie die Java Database Library verwenden können, während Sie RF auf Python laufen lassen, und erläutert auch, warum Sie das tun sollten. Außerdem werden wir die Bibliothek auch in der Praxis einsetzen, indem wir eine Verbindung zu einer IBM DB2-Datenbank herstellen und anschließend einige Schlüsselwörter ausführen. Bitte beachten Sie, dass ich diese Abhandlungen auch dazu nutzen werde, verschiedene Aspekte von RF zu beleuchten, auf die wir stoßen werden und die meiner Meinung nach für diejenigen von Interesse sein könnten, die die Interna von RF etwas besser verstehen möchten. Für einige Leser wird dies also eine milde und akzeptable (und vielleicht sogar willkommene) Abschweifung sein, während es für die praktisch veranlagten Leser eine unentschuldbare Übertretung darstellen mag. Man kann nicht alle für sich gewinnen, denke ich. :-)

Für den RF stehen derzeit zwei Datenbankbibliotheken zur Verfügung: eine ist in Python implementiert und unterstütztu.a. ODBC, während die andere in Java implementiert ist und JDBC unterstützt. Die weiteren Unterschiede zwischen diesen Bibliotheken (d.h. abgesehen von den Implementierungssprachen und den unterstützten Datenbank-APIs) und die Frage, wann man die eine und wann die andere verwenden sollte, werden in einem anderen Beitrag behandelt. In diesem Beitrag werde ich lediglich die Verwendung der Java Database Library in einem speziellen Kontext erläutern, nämlich der Verwendung über das sogenannte 'Remote Library Interface' (RLI). Über die RLI können wir diese Java-Testbibliothek mit einer RF-Instanz verwenden, die im CPython-Interpreter läuft. Aber lassen Sie uns zunächst etwas Licht in das Problem bringen, das wir mit dieser Konstruktion lösen wollen, sowie in einige der technischen Konzepte, die sowohl das Problem als auch seine Lösung umgeben.

Verwendung von RF-Testbibliotheken, die nicht zu Python gehören

Alles beginnt vielversprechend

Das Robot Framework ist in Python geschrieben. Da jedoch neben der Referenzimplementierung des CPython-Interpreters (den Sie bei der Installation von Python erhalten) auch eine Java-Portierung(Jython) sowie eine .NET-Portierung(IronPython) von Python verfügbar sind, können wir das RF auch auf diesen Plattformen (d.h. Java und .NET) ausführen. Dazu führen wir den RF einfach mit dem entsprechenden Interpreter aus (vorausgesetzt, dieser Interpreter wurde ordnungsgemäß installiert). Die RF ist also vollständig kompatibel mit Jython und IronPython und unterstützt in diesem Sinne von Haus aus die Verwendung dieser Interpreter: Sie benötigt weder C-Erweiterungsmodule noch Python-Bibliotheken, die in Jython oder IronPython nicht implementiert sind. Das Schöne daran ist, dass wir dadurch auch die Möglichkeit haben, RF-Testbibliotheken zu verwenden, die in Java oder .NET geschrieben wurden, indem wir RF auf/mit dem entsprechenden Interpreter ausführen. Folglich können wir auch Nicht-Python-Bibliotheken wie die Java JDBC Database Library verwenden, indem wir RF auf Jython laufen lassen. Der Jython-Interpreter kompiliert nicht nur den RF-Python-Code in Java-Bytecode für die Ausführung in einer JVM, sondern ermöglicht auch den Import von Java-Klassen (z.B. der Datenbankbibliothek) als (wenn sie) Python-Module wären.

Und dann gibt es natürlich einen Haken

Die Verwendung eines beliebigen Interpreters verhindert jedoch, dass wir Testbibliotheken ausführen, die mit diesem Interpreter nicht kompatibel sind. Das liegt daran, dass im Gegensatz zum RF nicht alle Testbibliotheken von Haus aus alle Interpreter unterstützen. Erstens sind Bibliotheken, die ausdrücklich für die Verwendung mit einem bestimmten Nicht-CInterpreter geschrieben wurden, wie z.B. Jython oder IronPython, zwangsläufig (und offensichtlich) auf diesen Interpreter beschränkt. Wenn Sie den RF unter Python ausführen, können Sie zum Beispiel keine .NET-Testbibliotheken und keine Java-Testbibliotheken ausführen. Ein Beispiel ist unsere Java-Datenbankbibliothek: Nur wenn wir sie unter Jython ausführen, können wir die entsprechenden Java-Klassen aus der DB-Bibliothek importieren und sie zusammen mit dem RF in der JVM ausführen. Dasselbe gilt für alle .NET-Bibliotheken, die wir nur verwenden können, wenn wir den RF auf IronPython ausführen. Wenn Sie den RF auf Jython ausführen, können Sie auch keine .NET-Bibliotheken verwenden. Und wenn Sie den RF unter IronPython ausführen ... nun, Sie verstehen schon. Aber zweitens (und vielleicht überraschenderweise) laufen selbst Testbibliotheken, die in Python geschrieben wurden, möglicherweise nicht auf einem oder beiden anderen Interpretern. Betrachten wir zum Beispiel Jython. Zum einen verfügt Jython nicht über so viele Build-in-Bibliotheken wie Python. Das heißt, nicht alle nativen Python-Build-in-Module haben ein Gegenstück in Jython. Außerdem hängen bestimmte Python-Bibliotheken selbst von in C geschriebenen Modulen ab, die Jython nicht verarbeiten kann. So kann eine RF-Testbibliothek, obwohl sie in reinem Python geschrieben ist, von einem C-Erweiterungsmodul abhängen (oder von einem Python-Modul, das wiederum von einem C-Erweiterungsmodul abhängt), was für den CPython-Interpreter kein Problem darstellt, aber für den Jython-Interpreter ein Problem ist. In ähnlicher Weise kann eine in Python geschriebene RF-Testbibliothek von einer CPython-Baubibliothek abhängen, die noch nicht für Jython neu implementiert wurde. All dies gilt auch für IronPython. Da die meisten (verwendeten) RF-Testbibliotheken in Python geschrieben wurden (und werden) und/oder von C-Erweiterungen oder von Modulen abhängen, die in anderen Interpretern nicht implementiert sind, ist es daher vorzuziehen, die RF unter Python auszuführen. Wenn wir zum Beispiel den RF wegen der JDBC-Datenbankbibliothek unter Jython ausführen, können wir so wichtige Python-Testbibliotheken wie die beiden HTTP-Bibliotheken und die SUDS (SOAP)-Bibliothek nicht verwenden, da sie alle von Modulen abhängen, die nicht mit Jython kompatibel sind. Wenn wir also die Java-Datenbankbibliothek mit Jython ausführen würden, würden wir effektiv mehrere wichtige Testbibliotheken verlieren. Für mich ist dieser Nachteil in vielen Situationen ein Hemmschuh.

Aber es wäre nicht Robot Framework ohne ein Happy End

Zum Glück gibt es eine einfache Möglichkeit, Java- oder .NET-Testbibliotheken zu verwenden und den RF trotzdem unter Python laufen zu lassen, wodurch der Nachteil vermieden wird, dass der RF auf einem der Ports läuft. Sie können sogar Testbibliotheken in anderen Sprachen schreiben (für die Python keine Ports hat) und sie trotzdem unter Python ausführen! Zum Beispiel Testbibliotheken, die in Ruby, nodeJS, PHP, Perl oder anderen Sprachen geschrieben wurden. Das ist wirklich eine tolle Sache: die Verwendung von Testbibliotheken, die in verschiedenen Sprachen entwickelt wurden, in ein und demselben Testsatz, Testfall oder sogar in derselben Anweisung! Sie können jede beliebige Testbibliothek verwenden, unabhängig von der Sprache, in der sie implementiert ist. Darüber hinaus können Ihre eigenen Teammitglieder ihre Testbibliotheken in der Sprache zur Verfügung stellen, die sie am besten beherrschen und mit der sie sich am wohlsten fühlen, wodurch die Schwelle für einen solchen Beitrag gesenkt wird. Natürlich möchten Sie nicht eine Unzahl verschiedener Sprachen in Ihre Automatisierungsprojekte einbeziehen und es ist fraglich, ob die Verwendung von nur zwei verschiedenen Sprachen überhaupt wünschenswert ist, da ein solcher Ansatz gewisse Risiken und Nachteile mit sich bringt. Aber selbst wenn Sie sich auf eine Sprache beschränken, ist die Tatsache, dass Sie zwischen so vielen Sprachen wählen können, eine einzigartige und leistungsstarke Eigenschaft dieses Testautomatisierungsframeworks. Und natürlich ist der wichtigste Anwendungsfall immer relevant, nämlich die Möglichkeit, alle Bibliotheken von Drittanbietern zu verwenden, die im RF-Ökosystem vorhanden sind, unabhängig von der Sprache, in der sie geschrieben wurden: Sehen Sie eine Ruby-Bibliothek, die Sie verwenden könnten? Nehmen Sie sie einfach und führen Sie sie zusammen mit Ihren Python-, Java- und anderen Bibliotheken aus! Der Mechanismus, mit dem all dies erreicht wird, ist die Remote Library Interface (RLI).

Die Schnittstelle zur Fernbibliothek

Ich werde hier weder die Interna noch die Verwendung des RLI im Detail beschreiben, zum einen, weil bestimmte Informationen bereits verfügbar sind (z.B. über die RLI-Projektseite und das RF-Benutzerhandbuch), zum anderen, weil beide Themen in einem anderen Beitrag behandelt werden. Wie Sie der GitHub-Projektseite entnehmen können, ermöglicht der RLI die Ausführung einer Testbibliothek als externer Prozess, d.h. auf einem anderen Hostsystem (oder zumindest einem Prozess) als dem, auf dem der RF selbst (in) läuft. Wie wir noch sehen werden, ermöglicht dies auch ein leistungsfähiges verteiltes Testsystem. Aber es ermöglicht auch die Verwendung von Testbibliotheken, die in Sprachen geschrieben sind, die mit dem Interpreter, den Sie während Ihrer RF-Testläufe verwenden, nicht kompatibel sind. Letzteres ist das, was uns (hauptsächlich) interessiert. Schauen wir uns also an, wie das alles zustande kommt. Auf der höchsten Ebene sind drei Komponenten beteiligt: eine Client-Komponente, eine (entfernte) Server-Komponente und die eigentliche(n) Testbibliothek(en), die der Plattform zur Verfügung gestellt werden soll(en). Streng genommen besteht der RLI also aus der ersten und zweiten dieser Komponenten. Schauen wir uns daher beide genauer an.

Die Client-Komponente

Die erste Komponente heißt 'Remote'-Bibliothek und ist eine der Standard-Testbibliotheken, die mit dem RF mitgeliefert werden (zum Vergrößern auf ein Bild klicken):

Daher importieren wir die Remote-Bibliothek wie jede andere Testbibliothek. Zum Beispiel in RIDE (einer der vielen möglichen Editoren zum Schreiben von RF-Testcode): (Wie wir später noch lernen werden, ist das Importieren der Remote-Bibliothek der letzte Schritt bei der Einrichtung des RLI-Mechanismus.) Die importierte Remote-Bibliothek fungiert als Client für die zweite Komponente (die Serverkomponente, siehe nächster Abschnitt) und ist somit die Verbindung zwischen dem RF einerseits und dieser zweiten Komponente andererseits. Das Argument im obigen Screenshot (das treffend benannte 'Args') weist der Remote-Bibliothek den Weg zu dem Server, mit dem sie sich verbinden soll. Das heißt, die URL und der Port bezeichnen das Hostsystem, auf dem sich der entfernte Serverteil befindet, und den Port, an dem er lauscht. Und der Teil /JMSLibrary gibt den Namen der Testbibliothek an, die von der entfernten Komponente bereitgestellt wird. Die Testbibliothek implementiert die Schlüsselwörter und ist somit die Komponente, an die der entfernte Server alle Schlüsselwortaufrufe, die er von der Remote-Client-Bibliothek erhält, weiterleiten sollte. Wir könnten also eine weitere Remote-Bibliotheksimport-Anweisung haben, die sich mit derselben Instanz des entfernten Servers verbindet, aber eine andere, in dieser Instanz laufende Testbibliothek adressiert (anvisiert). Tatsächlich können wir beliebig viele solcher Importanweisungen für dieselbe oder andere entfernte Serverinstanzen haben, die auf demselben oder auf verschiedenen Hostsystemen laufen! Dies ermöglicht auch eine leistungsstarke verteilte Testausführung. Natürlich ist das Hostsystem eines Remote-Servers nicht unbedingt ein externes System, sondern kann durchaus das System sein, auf dem der RF läuft (localhost). Dementsprechend zeigt der folgende Screenshot ein Setup mit drei (nicht vier) Remote-Server-Instanzen: eine, die auf localhost läuft und zwei Bibliotheken (HelloWorld und StackTest) bereitstellt, eine weitere, die ebenfalls auf localhost läuft, aber nur eine Bibliothek (JMSLibrary) bereitstellt, und schließlich eine, die auf einem externen System läuft und ebenfalls eine Bibliothek (SomeLibrary) bereitstellt.

Wir können also eine Verbindung zu mehreren Remote-Servern (die jeweils mehrere Testbibliotheken bedienen) auf jedem von mehreren Hostsystemen herstellen. Wenn Sie mehrere Remote-Server auf ein und demselben Host-System betreiben, muss natürlich jeder Remote-Server-Instanz eine eindeutige Portnummer zugewiesen werden. Der Unterschied zu anderen Testbibliotheken besteht darin, dass die Remote-Client-Bibliothek selbst keine Schlüsselwörter enthält, sondern dass durch sie die in der Remote-Testbibliothek enthaltenen Schlüsselwörter dem RF zur Verfügung gestellt werden. Wie alle anderen RF Testbibliotheken wurde auch die Remote-Bibliothek gegen die API der RF-Bibliothek geschrieben. Doch anstatt ihre eigenen Schlüsselwörter über diese API der Plattform zur Verfügung zu stellen, fungiert sie lediglich als Proxy, der nichts weiter tut, als Schlüsselwortaufrufe von unserem RF-Testcode an die Remote-Serverkomponente weiterzuleiten und die möglichen Rückgabewerte, die der Remote-Server von einem ausgeführten Testbibliotheksschlüsselwort erhalten hat und die er dann an den Client zurückübermittelt hat, an den RF und letztlich an unseren Testcode weiterzuleiten.

Die Server-Komponente

Die zweite Komponente des RLI-Mechanismus ist der so genannte 'Remote Server'. Dies ist die zentrale Komponente, das "Herz" des RLI, in dem sich die ganze Magie abspielt.

Mehr (noch mehr) Flexibilität und Vielseitigkeit: Portierung von Testbibliotheken

Wie bereits im vorigen Abschnitt beschrieben, handelt es sich um eine 'lose gekoppelte' Komponente, die per Fernzugriff ausgeführt werden kann und eine oder mehrere Testbibliotheken bedient, die die eigentlichen Schlüsselwörter implementieren, die wir im Framework zur Verfügung haben müssen. Solche Bibliotheken wurden ausdrücklich für den RLI geschrieben, der es einem Remote-Server ermöglicht, die in diesen Bibliotheken implementierten Schlüsselwörter der Remote-Client-Bibliothek zur Verfügung zu stellen. Der Client wiederum stellt die Schlüsselwörter der RF Plattform zur Verfügung. Bei den Bibliotheken, die auf diese Weise zur Verfügung gestellt werden können, kann es sich um Bibliotheken handeln, die Sie selbst geschrieben haben, oder um bestehende, gemeinsam genutzte Bibliotheken von Drittanbietern innerhalb des RF Ökosystems. Solche Testbibliotheken können in Java, Python, Ruby, PHP oder verschiedenen anderen unterstützten Sprachen geschrieben werden, je nach Ihren Bedürfnissen. Für jede unterstützte Sprache wurde eine Implementierung der Remote Server Komponente zur Verfügung gestellt. Von der RLI GitHub Projektseite:

Sprache / Plattform:	Remote Server-Implementierung:
Python	PythonRemoteServer
Java	jrobotremoteserver
Ruby	robot-remote-server-rb
.NET	nrobotremote
Clojure	robot-remote-server-clj
Perl	plrobotremoteserver
node.js	Knoten-Roboter-Remoteserver
PHP	phrrs

Eine Remote-Server-Implementierung kann für (in) jede Sprache erstellt werden, die xml-rpc unterstützt, wie z.B. die Sprachen in der Tabelle. Eine Remote-Bibliotheksinstanz (Client) und ein Remote-Server kommunizieren über ein einfaches, proprietäres'Remote-Protokoll' auf der Grundlage von xml-rpc. Xml-rpc ist ein Protokoll, das xml als Format für die Nachrichten verwendet, die Sie transportieren möchten, und http als eigentlichen Transportmechanismus. Daher die URLs in den Import-Anweisungen: Client und Server rufen sich gegenseitig über http auf (und stellen so eine Verbindung her). Da jeder Remote-Server, unabhängig von der Sprache, in der er implementiert ist, über eine Instanz derselben Remote-(Client-)Bibliothek, die in Python implementiert ist, eine Verbindung zum Framework herstellt, können wir eine Verbindung zu jeder Testbibliothek herstellen, die nicht in Python implementiert ist, ohne dass sie auf etwas anderem als unserem vertrauten CPython-Interpreter laufen muss! Der jrobotremoteserver kann beispielsweise Testbibliotheken bereitstellen, die in Java geschrieben wurden. Da wir uns über die Remote-Bibliothek mit diesem Remote-Server verbinden können, können wir die Java-Bibliotheken auch dann verwenden, wenn der RF unter Python läuft: Im obigen Setup können wir eine Verbindung vom RF, der auf Python läuft, zur Java-Datenbankbibliothek herstellen, die in der JVM (auf demselben System) läuft. Um beispielsweise überprüfen zu können, ob das SUT als Reaktion auf einen REST-Aufruf, der über eine RF REST-Testbibliothek erfolgt, die wir mit dem CPython-Interpreter ausführen müssen, die korrekten Datenbankeinfügungen vorgenommen hat, können wir mit dem RLI, insbesondere durch die Bereitstellung des entsprechenden Remote-Servers, eine Testbibliothek 'portieren'. Mit 'Portierung' meine ich den Prozess, einem Interpreter (wie dem CPython-Interpreter) eine Bibliothek zur Verfügung zu stellen, die an sich nicht mit diesem Interpreter kompatibel ist (z.B. eine in Java geschriebene Testbibliothek). Der RLI bietet einen solchen Prozess oder Mechanismus zur Portierung solcher Bibliotheken auf einen Interpreter. Wie die verschiedenen Remote-Server verteilt werden und auf den Host-Systemen eingesetzt werden müssen und wie sie sich in die eigentlichen Testbibliotheken integrieren und mit ihnen interagieren, hängt von der jeweiligen Implementierungssprache sowie vom Design des Remote-Servers ab. Der jrobotremoteserver zum Beispiel wird als ausführbare jar-Datei verteilt und verwendet einen Jetty-Servlet-Container, um die Testbibliotheken auszuführen. Detaillierte Informationen über den Einsatz des jrobotremoteservers finden Sie weiter unten.

Mehr (noch mehr) Leistung: Remote-Ausführung und verteilte Ausführung

Neben der Portierung von Testbibliotheken gibt es weitere wichtige Anwendungsfälle für den RLI: Remote-Ausführung und verteiltes Testen. Remote-Testausführung bedeutet, dass die Testbibliothek (oder Bibliotheken) auf einem anderen Hostsystem als dem RF selbst ausgeführt wird (werden). Eine Remote-Einrichtung ist notwendig, wenn es nicht möglich ist, ein SUT (System under Test) aus der Ferne aufzurufen. Eine webbasierte Anwendung, die z.B. eine REST-API verwendet oder über SOAP zugänglich ist, kann immer aus der Ferne aufgerufen werden, indem die HTTP- oder SOAP-Bibliothek von RF verwendet wird: eine Remote-Bibliotheksschnittstelle ist nicht erforderlich. Das Gleiche gilt für das Testen dieser Webanwendung auf GUI-Ebene mit Selenium Webdriver, da der remote gehostete Webinhalt über http in unseren lokalen Browser geladen wird (und mit dem Selenium Grid können wir sogar Browserinstanzen auf entfernten Systemen verwenden). Aber vielleicht haben wir eine eigenständige Java-Anwendung, die wir auf API-Ebene testen möchten. Dazu müssen wir unsere eigenen Java-Testbibliotheken mit 'Glue Code' erstellen: kleine Wrapper-Funktionen, die die Intelligenz zum korrekten Aufruf unserer API-Funktionen enthalten. Über diese Testbibliothek werden diese Wrapper-Funktionen dem RF als Schlüsselwörter zur Verfügung gestellt, über die wir dann die API-Funktionen in unserem Testcode aufrufen können. Daher auch der Begriff 'Glue Code' (mehr dazu in einem Folgebeitrag). Normalerweise wird das SUT auf einem System in unserer Staging-Umgebung gehostet (ebenso wie andere Komponenten, z.B. eine Datenbank), während unser automatisiertes Test-Framework auf einem separaten Server liegt, der in der Regel eng in unsere Continuous Integration-Infrastruktur/-Setup integriert ist. Da das SUT jedoch erfordert, dass sich der Aufrufer auf demselben System befindet, können wir unsere erstellten Testbibliotheken nicht einfach auf dem Tooling-Server ausführen. Wir stellen daher (die Java-Implementierung des) Remote-Servers auf dem SUT-System bereit und lassen ihn unsere Java-Testbibliotheken bereitstellen, so dass wir diese Testbibliotheken aus der Ferne ausführen und aufrufen können:

Die Testbibliotheken laufen nun im Remote Server auf dem entfernten System, auf dem auch das SUT läuft. (Beachten Sie, dass es sich hierbei um eine Vereinfachung handelt: In einem späteren Beitrag werden wir auf einige der Komplexitäten eingehen, die mit dem Testen gegen eine Java-API verbunden sind.) Wie Sie sehen werden (und daher hier nicht weiter erläutert werden), eröffnet die Möglichkeit, einen oder mehrere Remote-Server auf einem oder mehreren lokalen und/oder entfernten Systemen laufen zu lassen, wobei jeder Remote-Server wiederum eine oder mehrere Testbibliotheken ausführt, endlose Möglichkeiten im Hinblick auf ein verteiltes/paralleles/gleichzeitiges Test-Setup.

Völlig transparent und nicht aufdringlich

Bitte beachten Sie, dass die beschriebene Vielfalt/Multitude an verfügbaren Remote-Servern (wie in der Tabelle dargestellt) den Benutzern des RF völlig verborgen bleibt, selbst wenn mehrere oder alle diese Server in Gebrauch sind. Tatsächlich ist der gesamte RLI-Mechanismus für die Benutzer des RF völlig transparent. Wenn Sie einen oder mehrere (verschiedene) Remote-Server verwenden, müssen die entsprechenden Server zunächst auf den jeweiligen (lokalen und/oder entfernten) Hostsystemen eingerichtet werden (mehr dazu in den nächsten Abschnitten). Dann muss für jede Testbibliothek, die auf einem der Remote-Server ausgeführt wird, eine einzelne Importanweisung in den RF-Automatisierungscode eingefügt werden. Diese Anweisung importiert die Remote-(Client-)Bibliothek, wie bereits im Screenshot oben gezeigt. Über das Argument url wird der Remote-Client auf den Remote-Server verwiesen, mit dem er sich verbinden soll, sowie auf die Ziel-Testbibliothek, die über diese Verbindung verfügbar gemacht werden soll. Über das Argument 'Alias' können wir dieser Ressource (d.h. der entfernten Testbibliothek) einen logischen Namen geben. Innerhalb des RF ist die Ressource von da an unter diesem logischen Namen bekannt und kann folglich auch innerhalb des Automatisierungscodes unter diesem Namen angesprochen werden. Sowohl die Tatsache, dass es sich bei der Bibliothek um eine Remote-Bibliothek handelt, als auch die Tatsache, dass sie in einer anderen Sprache geschrieben ist (als der RF und/oder andere Testbibliotheken), spielt für den Benutzer keine Rolle und der RF verbirgt diese Tatsachen daher vollständig vor dem Benutzer. Für den RF und seine Benutzer ist es einfach nur eine weitere Testbibliothek, die der Plattform zur Verfügung steht. Beachten Sie, dass selbst die Import-Anweisung nichts darüber aussagt, ob eine Bibliothek in Ruby, Java, Python usw. vorliegt (obwohl sie etwas darüber aussagt, dass sie extern ist, wenn auch nur in dem Sinne, dass sie in einem anderen Prozess läuft). Der folgende Screenshot veranschaulicht die vollständige und völlige Transparenz des Mechanismus. Er zeigt die Tooltip-Hilfe und die Autovervollständigung (wiederum in RIDE) für die Java-Datenbankbibliothek, die als Remote-Testbibliothek unter dem logischen Namen 'DBLibrary' importiert wurde

Ausführen der Java-Datenbankbibliothek

Wie bereits erwähnt, könnte unsere Motivation für die Verwendung der RLI zur Bereitstellung von Testbibliotheken für den RF darin bestehen, dass wir sie aus der Ferne und/oder verteilt ausführen müssen oder dass wir Bibliotheken ausführen müssen, die in Sprachen geschrieben wurden, die nicht mit dem Interpreter kompatibel sind, mit dem wir unsere RF-Testläufe ausführen müssen. Letzteres ist die Motivation, die uns hier antreibt, denn wir sind daran interessiert, die Java Database Library zu verwenden und gleichzeitig den RF (und damit unsere Tests) auf Python laufen zu lassen. Lassen Sie uns also die obige Theorie in die Praxis umsetzen, indem wir die Java DB Library mit dem RLI ausführen. Als Beispiel werden wir eine Verbindung zu einer IBM DB2 Datenbank herstellen. Das ist natürlich nicht nötig: Wir können auch die Python Database Library verwenden, um uns über ODBC mit DB2 zu verbinden. Wie bereits erwähnt, wird die Frage, welche Datenbanktestbibliothek in welchen Situationen zu bevorzugen ist (und warum), in einem Folgebeitrag behandelt.

Über die Bibliothek

Da es sich um eine JDBC-Bibliothek handelt, ist die Datenbankbibliothek in Java geschrieben. Sie wird als ausführbare jar-Datei verteilt. Als solche kann sie nur in einer JVM ausgeführt werden und kann folglich nicht von einer RF-Instanz verwendet werden, die im CPython-Interpreter läuft. Dennoch möchten wir die Bibliothek verwenden, während wir den RF unter Python ausführen. Zu diesem Zweck können wir den jrobotremoteserver verwenden, die Remote-Server-Implementierung für Java. Der jrobotremoteserver wird als ausführbare jar-Datei verteilt und verwendet einen gebündelten Jetty-Servlet-Container, um in Java geschriebene Testbibliotheken auszuführen/zu bedienen. Diese Testbibliotheken sind Java-Klassendateien (möglicherweise in einer jar-Datei verpackt). Wir können eine oder mehrere solcher Testbibliotheken laden, indem wir den jrobotremoteserver von der Kommandozeile aus (wahrscheinlich mit einer Batch-Datei) mit dem Schalter '--library' für jede Testbibliothek, die wir verwenden möchten, starten. Zum Beispiel (unter der Annahme, dass sich alle beteiligten Java-Ressourcen auf dem Klassenpfad befinden): Java org.robotframework.remoteserver.RemoteServer --library JMSLibrary:/someAlias --port 8270 Damit starten Sie den jrobotremoteserver und lassen ihn die JMSLibrary bereitstellen. In einem separaten Beitrag wird ein Beispiel für die Erstellung einer Java-Testbibliothek von Grund auf gezeigt, die auf diese Weise im jrobotremoteserver bereitgestellt wird. Zu unserem Vorteil hat der Autor der Java Database Library eine zweite Distribution erstellt, die den jrobotremoteserver paketiert und wiederverwendet, so dass eine Remote-Datenbankbibliothek zur Verfügung steht, die sofort verwendet werden kann. Nachdem Sie das Github-Projekt Database Library heruntergeladen haben (siehe nächster Abschnitt), können Sie die beiden Distributionen sehen:

Schauen wir uns nun an, wie Sie das Ganze zum Laufen bringen!

Die Bibliothek in Gebrauch nehmen

Vorausgesetzt, dass Windows als Betriebssystem, Python, Robot Framework, IBM DB2 (z.B. das kostenlose'DB2 Express-C') und Java JRE/JDK (6 oder höher) darauf installiert sind und RIDE (Robot Framework Integrated Development Environment) als unser Editor:

Bereitstellung der Bibliothek auf der Plattform

• Weiter zu: https://github.com/ThomasJaspers/robotframework-dblibrary/
• Klicken Sie auf die grüne Schaltfläche 'Klonen oder Herunterladen' und anschließend auf die Schaltfläche 'ZIP herunterladen' und speichern Sie die Datei 'robotframework-dblibrary-master.zip' auf Ihrer lokalen Festplatte.
• Gehen Sie zum Ort des Downloads und extrahieren Sie (in einen Zielordner) die Datei 'dblibrary-2.0-server.jar', die sich im Ordner 'robotframework-dblibrary-mastersample' der heruntergeladenen Datei 'robotframework-dblibrary-master.zip' befindet. (Die nebenstehende Datei dblibrary-2.0.jar ist die 'normale' Datenbankbibliothek, die in einer JVM ausgeführt werden muss und daher nur verwendet werden kann, wenn RF auf Jython läuft).
• Hinweis: Im Ordner 'robotframework-dblibrary-master' der Zip-Datei finden Sie die Schlüsselwortdokumentation: 'DatabaseLibrary_v20.html'. Vielleicht möchten Sie diese auch extrahieren.
• Bevor Sie die Datenbankbibliothek innerhalb von Robot Framework verwenden können, müssen Sie das extrahierte jar ausführen (siehe oben für eine Beschreibung, wie das funktioniert). Sehen Sie sich die nächsten paar Schritte an.
• Navigieren Sie zu dem Zielordner (in den Sie die jar-Datei extrahiert haben)
• Erstellen Sie in diesem Ordner eine Batch-Datei mit dem folgenden Inhalt:

@echo off

set CLASSPATH=%CLASSPATH%;%~dp0dblibrary-2.0-server.jar;%~dp0db2jcc.jar;%~dp0db2jcc_license_cu.jar

java org.robot.database.server.RemoteServer --port 8271

Einige Bemerkungen dazu:

In Zeile 3 muss Java in der Lage sein, die Klasse RemoteServer zu finden und auszuführen, was letztendlich dazu führt, dass der Remote-Server, Jetty und die eigentliche Datenbank-Testbibliothek geladen werden. Zu diesem Zweck müssen wir die Datei dblibrary-2.0-server.jar (die diese Klasse enthält) zum Klassenpfad hinzufügen.

Daher erweitern wir in Zeile 2 die Windows-Systemvariable 'classpath' (vorausgesetzt, es gibt eine) um den Pfad zum jar. Die Datenbankbibliothek selbst benötigt jedoch den entsprechenden jdbc-Treiber für den Datenbankzugriff: Ohne ihn können wir keine Verbindung zur Datenbank herstellen. Ein Datenbankanbieter wie Oracle oder IBM stellt seine eigenen jdbc-Treiber zur Verfügung. Da wir in unserem Fall auf IBMs DB2 zugreifen möchten, müssen wir auch den entsprechenden Treiber in den Klassenpfad aufnehmen. Bevor jedoch die eigentliche jdbc-Verbindung zwischen dem jdbc-Treiber und der Datenbank hergestellt wird, prüft der jdbc-Treiber, ob eine Verbindung zum Server tatsächlich lizenziert (erlaubt) ist. Zu diesem Zweck müssen wir auch die richtige Lizenzdatei auf dem Klassenpfad haben. In diesem Beispiel ist der Treiber in der Datei 'db2jcc.jar' und die Lizenz in der Datei 'db2jcc_license_cu.jar' enthalten. Um den richtigen Treiber und die richtige Lizenz in Ihrem eigenen Kontext zu ermitteln, wenden Sie sich bitte an Ihren DB-Administrator oder konsultieren Sie diese Übersicht der Treiberversionen (Sie können die Treiber auch von dort herunterladen). Allgemeine Informationen zu DB2 jdbc-Treibern (z.B. zu den Unterschieden in den Typen) hier, hier und hier. Informationen über die Lizenzdatei: hier.

Bitte beachten Sie außerdem, dass Sie die Pfade zu den drei Jars auch zu einer bestehenden Windows-Klassenpfad-Systemvariable im Dialog 'Umgebungsvariablen' statt in dieser Batch-Datei hinzufügen können.

Beachten Sie auch, dass ich in Zeile 2 '%~dp0' verwende, um den Ordner zu bezeichnen, in dem sich die Batch-Datei selbst befindet. Dies setzt voraus, dass sich alle drei jar-Dateien im selben Ordner wie die Batch-Datei befinden (und funktioniert folglich nur, wenn sie sich dort befinden). Sie können auch andere Bezeichnungen verwenden, z.B. einen vollständig qualifizierten Pfadnamen zu jeder der Ressourcen (d.h. jar-Dateien).

Und schließlich beachten Sie bitte, dass Sie die Batch-Datei (und damit die Remote DB Library) auch aus Ihrem RF-Testcode heraus starten können, z.B. über eine Setup-Funktion.

• Führen Sie die Batch-Datei aus (mit einem Doppelklick oder in einem Befehlszeilenfenster).
• Erstellen Sie im Testcode eine Importanweisung für die Testsuite oder die Schlüsselwortressource, in der Sie die Schlüsselwörter der Datenbankbibliothek verwenden möchten:

• Mit diesen Schritten haben wir die Datenbankbibliothek für den RF verfügbar gemacht. Wir sind nun bereit, die in der Bibliothek enthaltenen Schlüsselwörter für den Zugriff auf unsere DB2-Datenbank zu verwenden.

Verbindung zu einer Datenbank herstellen

• Der erste Schritt besteht darin, eine Verbindung zur Datenbank herzustellen. Dies geschieht in der Regel im Rahmen eines Setups. In ähnlicher Weise erfolgt das Trennen der Verbindung durch einen Teardown. Es würde den Rahmen dieses Beitrags sprengen, auf die Setup-/Teardown-Funktionen im Detail einzugehen (wann/wie/warum sie zu verwenden sind, typische Fallstricke bei ihrer Verwendung usw.): Auch dies wird Thema eines anderen geplanten Beitrags sein.

Bemerkungen:

Das erste Argument ist der vollständig qualifizierte Paketname der IBM jdbc-Treiberklasse, wie sie im Treiber-Jar enthalten ist (wie oben erwähnt).

Das zweite Argument ist die jdbc-URL. Informationen dazu finden Sie zum Beispiel auf dieser Website. Beachten Sie, dass meine jdbc-URL auf die SAMPLE-Datenbank verweist, die mit DB2 Express-C ausgeliefert wird. Die wenigen Zeilen in meinem Beispiel-'Testfall' (siehe nächster Punkt) verwenden diese SAMPLE-Datenbank.

Der dritte und vierte Parameter sind die für die Verbindung erforderlichen Anmeldeinformationen.

Verwenden Sie die Schlüsselwörter der Datenbankbibliothek in Ihrem Testcode

• Nachdem wir nun eine richtige Verbindungsanweisung hinzugefügt haben, können wir mit der Abfrage oder Manipulation der Datenbank beginnen. Die folgenden Zeilen sind nur zufällige Beispiele für Schlüsselwörter, die wir nun in unseren wiederverwendbaren Testfunktionen (d.h. Schlüsselwörtern) und Testentwürfen (Testfällen), die wir aus den Testfunktionen erstellen, verwenden können. Beachten Sie also bitte, dass die folgenden Zeilen keinesfalls als Beispiel für einen sinnvollen, effektiven oder gut strukturierten Testfall zu verstehen sind! Der 'Testfall' ist lediglich eine willkürliche Zusammenstellung von Beispielen für Schlüsselwortaufrufe. Sie müssen (Schichten von) Domänenfunktionen (und wahrscheinlich andere Arten von wiederverwendbaren Ressourcen) erstellen und Ihre Testentwürfe aus diesen Domänenfunktionen entwickeln (siehe einige meiner anderen Blogbeiträge).

Beachten Sie, dass ich mir hier nicht einmal die Mühe mache, die Ausgabe (Rückgabe) des Schlüsselworts 'Execute Sql' einer Variablen zuzuweisen.

Beachten Sie bitte, dass in dem Beispiel den Schlüsselwortnamen 'DBLibrary' vorangestellt ist. Wie ich bereits erklärt habe, ist 'DBLibrary' der logische Name oder Alias für die jdbc-Datenbankbibliothek. Ich stelle diesen Alias hier den Schlüsselwortnamen voran, weil ich auch die andere RF-Datenbankbibliothek (die Python-Bibliothek, siehe oben) installiert habe. Da diese beiden Bibliotheken bestimmte Schlüsselwortnamen gemeinsam haben, stelle ich den Alias standardmäßig einem Schlüsselwortnamen voran, um Verwirrung und mögliche Konflikte zu vermeiden. Wenn Sie nur eine Datenbankbibliothek verwenden, ist die Voranstellung nicht notwendig.

• Führen Sie den Test durch und prüfen Sie die Ergebnisse:

• Die Mission ist erfüllt!

Zusammenfassung

Die Ausführung des RF auf einem bestimmten Interpreter schränkt möglicherweise die Verfügbarkeit von Testbibliotheken ein, die wir benötigen, um verfügbar zu sein. Der RLI ist ein einfacher Mechanismus, der die Portabilität und Skalierbarkeit des RF erheblich verbessert und es uns ermöglicht, bei dem Interpreter unserer Wahl zu bleiben, ohne die Testbibliotheken zu verlieren, die an sich nicht mit diesem Interpreter kompatibel sind. Unter Python können wir Nicht-Python-Bibliotheken verwenden (z.B. in Java, Ruby, PHP usw. geschrieben), unter Jython können wir Nicht-Java-Bibliotheken verwenden (z.B. in Python mit C-Erweiterungen, Ruby, PHP usw. geschrieben) und unter IronPython können wir Nicht-.Net-Bibliotheken verwenden (z.B. in Java, Perl, PHP usw. geschrieben). Dadurch können wir auch Tests auf entfernten Systemen ausführen, die keine Remote-Aufrufstrukturen zulassen, oder eine verteilte Testinfrastruktur einrichten. Die Java-Datenbankbibliothek ist ein Beispiel für eine Bibliothek, die über den RLI verwendet werden kann. In unserem Beispiel haben wir diese Java-Bibliothek verwendet, um erfolgreich eine Verbindung zu einer IBM DB2-Datenbank herzustellen, während wir den RF unter Python ausführen.