Ausführen des Remote Servers von Robot Framework als Java-Agent

Robot Framework ist ein großartiges Tool für automatisierte Tests, das einen schlüsselwortgesteuerten Ansatz verwendet. Wenn Sie Robot Framework-Tests im Kontext eines laufenden Systems unter Test ausführen möchten, können Sie den RemoteServer von Robot Framework als Java-Agent laden. Da dies nicht standardmäßig möglich ist, erklären wir Ihnen hier, wie Sie es tun. Robot Framework verfügt über einen großartigen und einfachen Mechanismus, um Tests aus der Ferne auszuführen. Dieser Mechanismus bietet auch die Möglichkeit, Testbibliotheken auszuführen, die in Sprachen implementiert wurden, die mit dem Interpreter, auf dem Robot Framework läuft, nicht kompatibel sind. Wenn Sie beispielsweise Robot Framework auf Python ausführen, können Sie Testbibliotheken verwenden, die in Java geschrieben wurden. Um letzteres zu tun, müssen wir die Java-Implementierung des Robot Framework Remote Server verwenden. Genau das werden wir im Rahmen dieses Beitrags tun. Bitte lesen Sie diesen Blog-Beitrag für eine detaillierte Beschreibung dieser und anderer Aspekte der Remote Library Interface. In diesen Beiträgen finden Sie weitere Informationen über das Robot Framework im Allgemeinen. Der Java Remote Server lädt jedoch standardmäßig Klassen innerhalb seines eigenen Classloaders. Das ist in Ordnung, wenn Sie einen gut partitionierten Code haben, in dem Sie nach Herzenslust mocken und stubben können, aber es hilft Ihnen nicht, wenn Sie ein umfangreiches Legacy-System haben, das Sie vollständig ausführen müssen, bevor irgendetwas funktioniert. Wir möchten also, dass der entfernte Server innerhalb der JVM des zu testenden Systems läuft, damit Sie auf seine Objekte zugreifen können. Die Lösung ist die Verwendung des Java-Agent-Mechanismus. Ein Java-Agent wird geladen, bevor die Hauptklasse der regulären Anwendung ausgeführt wird, und kann alle Klassen instrumentieren, bevor sie von der Anwendung geladen werden. Wir brauchen die Instrumentierungsfunktion hier nicht zu verwenden: Alles, was wir brauchen, ist die Tatsache, dass der Agent denselben Classloader wie die reguläre Anwendung verwendet und daher auf den Code der Anwendung zugreifen kann. Ja, dies ist in der Tat eine Hintertür in die Anwendung, also laden Sie den Agenten nur in Ihrer Testumgebung! :-) Der Trick mit den Java-Agenten besteht aus drei Teilen:

1. Eine Hauptklasse, die eine "premain"-Methode ähnlich der regulären "main"-Methode hat.
2. Eine Manifestdatei im jar mit einem Premain-Class-Eintrag.
3. Starten Sie die JVM mit dem Parameter -javaagent.

Schritt 0: Abrufen des RemoteServer-Codes

Unsere Arbeit ist relativ einfach, da wir den von ombre42 erstellten RemoteServer nutzen. Er instanziiert einen Jetty-Server, der das xml-rpc-Protokoll implementiert, das den Robot Framework-Client mit Remote-Servern verbindet. Er hat außerdem die nette Eigenschaft, dass Sie Testbibliotheksklassen als Parameter auf der Befehlszeile übergeben können, so dass Sie den RemoteServer nicht neu packen müssen, wenn Sie eine Testbibliothek ändern oder hinzufügen. Stellen Sie sicher, dass diese Abhängigkeiten in Ihrem POM enthalten sind (ändern Sie die Versionsnummern nach Bedarf): [xml] <Abhängigkeiten> <Abhängigkeit> <groupId>com.github.ombre42</groupId> <artifactId>jrobotremoteserver</artifactId> <Version>3.0</version> </dependency> <Abhängigkeit> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <Version>1.2.16</version> </dependency> </dependencies> [/xml]

Schritt 1: Erstellen Sie die Klasse premain

[java] package com.xebia.robotbackdoor; import java.lang.instrument.Instrumentation; import org.apache.log4j.Level; import org.apache.log4j.Logger; import org.robotframework.remoteserver.RemoteServer; public class RobotBackdoor { public static void premain(String args, Instrumentation inst) throws Exception { RemoteServer.main(args.split(" ")); } } [/java] Wie Sie sehen, nutzen wir die RemoteServer-Implementierung von ombre42: Wir führen diese lediglich in premain aus und übergeben die Argumente (siehe Schritt 3 für die Argumente, die in der Befehlszeile übergeben werden). Wenn Sie die Einstellungen jedoch selbst kodieren möchten (und die Testbibliotheken mit der premain-Klasse paketieren), können Sie sie wie folgt kodieren: [java] ...andere Importe... import com.xebia.mysystem.test.robotlibraries.MyTestLibrary; public class RobotBackdoor { public static void premain(String args, Instrumentation inst) throws Exception { RemoteServer.configureLogging(); Logger.getRootLogger().setLevel(Level.INFO); RemoteServer server = new RemoteServer(); server.putLibrary("/spam", new MyTestLibrary()); server.setPort(9999); server.start(); } } [/java] Für den Fall, dass Sie sich wundern (ich habe mich gewundert): der Server bleibt selbst am Laufen und wird nicht abgemeldet.

Schritt 2: Fügen Sie einen Premain-Class-Eintrag in das jar-Manifest ein

Eine Agentenklasse wird ähnlich wie Hauptklassen (Main-Class-Eintrag) gestartet: mit einem Premain-Class-Eintrag in der jar-Manifestdatei. In unserem Beispiel sorgt diese eine Zeile für die Magie: Premain-Class:com.xebia.robotbackdoor.RobotBackdoor Wenn Sie Maven verwenden, müssen Sie das Paket manipulieren, um den Eintrag hinzuzufügen. Dies geschieht mit den folgenden Ergänzungen zu Ihrem POM: [xml] <Plugins> ...andere Plugins... <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <Version>2.6</version> <Konfiguration> <Archiv> <manifestEntries> <Premain-Class>com.xebia.robotbackdoor.RobotBackdoor</Premain-Class> </manifestEntries> </archive> </configuration> </plugin> </plugins> [/xml]

Extra: Verpackung als fette Dose

Sie können das brauchen oder auch nicht, aber wir fanden es praktisch, ein "fat jar" zu erstellen, das alle Abhängigkeiten enthält, die der RemoteServer benötigt. Dies geschieht mit dem folgenden Zusatz zu Ihrem POM:Beachten Sie, dass wir das Shade-Plugin verwenden, das es dem anderen Plugin erlaubt, den Manifest-Eintrag hinzuzufügen. Ein anderes "Fat Jar"-Plugin, das wir ausprobiert haben, fügte einfach sein eigenes Manifest hinzu, ohne dass andere Plugins es manipulieren konnten. [xml] <Plugins> ...andere Plugins... <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <Version>2.4</version> <Hinrichtungen> <Ausführung> <Phase>Paket</Phase> <Ziele> <Tor>schatten</tor> </goals> <Konfiguration> <minimizeJar>false</minimizeJar> <filtert> <filtern> <Artefakt>*:*</Artefakt> <schließt aus.> <ausschließen>META-INF/*.SF</ausschließen> <ausschließen>META-INF/*.DSA</exclude> <ausschließen>META-INF/*.RSA</exclude> </excludes> </filter> </filters> </configuration> </execution> </executions> </plugin> </plugins> [/xml] Die Ausnahmen sind da, weil viele Abhängigkeits-Jars diese Sicherheitsdateien enthalten und die JVM sich sonst darüber beschwert.

Schritt 3: Starten Sie die JVM mit dem Parameter -javaagent.

Ein Java-Agent wird mit dem Parameter -javaagent wie folgt geladen (wenn Sie den obigen Code in eine "robotremoteagent.jar" verpackt haben): java -javaagent:/path/to/robotremoteagent.jar -jar MySystemUnderTest.jar Wenn Sie jedoch den dynamischen Lademechanismus von RemoteServer verwenden, müssen Sie Parameter übergeben, die sich von den regulären Parametern unterscheiden. Dazu fügen Sie dem Parameter -javaagent ="my parameter list" hinzu: java -javaagent:/path/to/robotremoteagent.jar="--library com.xebia.mysystem.test.robotlibraries.MyTestLibrary:/spam --port 9999" -jar MySystemUnderTest.jar Sie können mehrere --library Einträge hinzufügen.

Fazit und Downloads

Die Ausführung von Robot Framework-Tests im Kontext eines laufenden Systems kann erreicht werden, indem der RemoteServer als Java-Agent geladen wird. Sie finden die pom.xml und die .java-Datei hier: robotremoteagent-code. Für die wirklich Faulen: Hier ist die gepackte jar-Datei des Remote-Agenten (auf dem neuesten Stand zum Zeitpunkt der Erstellung dieses Beitrags): robotremoteagent-1.0.jar.