Robot Framework Tutorial 2016
Part 1: Installation
Part 2: Keywords
Part 3: Implementing Keywords in Java
Part 4: Selenium2Library as a drop-in replacement for SeleniumLibrary
Part 5: Integration with TeamCity CI-Server
Part 6: Integration with Jenkins
Part 7: File Processing
Part 8: Working with Collections
Part 9: Wrap-Up and Conclusion
The “old” Robot Framework Tutorial.
In the previous article of this series we have been seen how powerful the concept of Keywords is that the Robot Framework is providing. But of course there are limitations. For example if there is a need to test very specific technology or functionality. It is recommended to always first check carefully if there is already a Test Library available that can be used right away. This can save the effort to write and maintain an own Test Library.
But pretty sure there comes the time when the provided Test Libraries are not sufficient. Then it is time to grab your favorite programming language and start hacking some of your own Keywords. This can be done in a lot of programming languages, including Python and Java. Now comes the “but”: But if you want to run the Robot Framework in its pure Python installation you might get some hard times including Keywords written in any other programming language. This does not mean it will not be possible, but it might just not be the best way to try and do this. (Compare the explanation from the first post of this series dealing with this issue already.)
Robot Framework – Remote Interface
But is there then a good solution to this. As you might have guessed already the answer is yes :-). The Robot Framework supports a Remote Interface that enables users to write Keywords in many different programming languages (those are listed on the page linked before) and use them with the Python installation of the Robot Framework right away. As it is really little effort to turn your ordinary Robot Framework Library into a remote Library I would recommend to simply do it every time you write your own Keyword Library.
For those of you who cannot wait to see all the technical details just take a look at this GIT repository . It shows a complete example of implementing Keywords in Java including the implementation for the Remote-Server interface.
Beside the advantage of decoupling your Library from the need of a specific Robot Framework installation this also has the advantage that you can start your Test Library Servers on different hosts. Thus this also offers the possibility to implement some load balancing into your testing.
A simple Keyword Library in Java
The following code shows the implementation of a Keyword Library in Java that contains one Keyword, namely “Print Message”. This example can also be found from GitHub (as mentioned before).
1package de.codecentric.robot.sample.keywords;
2
3import org.robotframework.javalib.annotation.ArgumentNames;
4import org.robotframework.javalib.annotation.RobotKeyword;
5import org.robotframework.javalib.annotation.RobotKeywords;
6
7@RobotKeywords
8public class SampleKeywords {
9
10 @RobotKeyword("Print Message")
11 @ArgumentNames({"message"})
12 public void printMessage(String message) {
13 System.out.println(message);
14 }
15}
The example as such is pretty straightforward. It uses a few annotations that are provided by Robot Framework JavaLib. Other than that it is simply an ordinary Java method that does basically nothing in this example for the sake of simplicity. But everything could be implemented here from calling REST-services to checking mails or parsing complicated binary output. Hey, this is Java, so everything is possible :-).
Now comes the cool stuff!
Turning your Java Keywords into a Remote Library
With a few lines of code you can turn your – already existing – Java Library into a Remote Library.
1package de.codecentric.robot.sample;
2
3import org.robotframework.javalib.library.AnnotationLibrary;
4import org.robotframework.remoteserver.RemoteServer;
5
6public class SampleRemoteLibrary extends AnnotationLibrary {
7
8 public SampleRemoteLibrary() {
9 super("de/codecentric/robot/sample/keywords/*.class");
10 }
11
12 @Override
13 public String getKeywordDocumentation(String keywordName) {
14 if (keywordName.equals("__intro__")) {
15 return "Intro";
16 }
17
18 return super.getKeywordDocumentation(keywordName);
19 }
20
21 public static void main(String[] args) throws Exception {
22 RemoteServer.configureLogging();
23 RemoteServer server = new RemoteServer();
24 server.addLibrary(SampleRemoteLibrary.class, 8270);
25 server.start();
26 }
27}
Again we are using Robot Framework Java libraries for the most part of the job. Of course the example could be extended to make the port that is used (here 8270) configurable, but the basic concept stays as easy as it is shown here. You basically only need to pass you Java class implementing your Keywords to the RemoteServer-object that we are creating. Then call the start()-method and that’s it. As usual there is some Maven magic involved by using the Maven Assembly PlugIn to build a standalone JAR for the server right away. Of course that can be checked out on GitHub .
Now how can the whole thing be used?
Using Remote Server Keywords
After compiling the remote server Keyword Library you can simply start the (keyword) server as follows:
java -jar server/sample-remote-library-1.0-server.jar
Now inside your Tests Suite you can import that Test Library – in a bit specific way – and use the Keywords from it then as usual.
*** Settings ***
Library Remote http://localhost:8270
*** Test Cases ***
Call Remote Keyword
Print Message "Testnachricht"
Again the complete example can be found from – what should I say – GitHub . Well, it is easy as that. Maybe one thing to note here is of course the port number given in the import of the library. Obviously that one has to match the one used inside the implementation of the Remote Library.
Conclusion
Implementing Test Libraries in Java is really easy. And it is close to zero effort to turn them into Remote Libraries which makes them much more versatile to use. I would simply recommend doing this always from the beginning to have all options in using the library. In the end it is of course also an advantage to have the possibility to run those libraries on different servers. This can be used to optimize performance of the test execution and can as well be a solution to some access restrictions where it might be required that testing functionality is running on the same server as some of the application services. There are quite some options for this. I like it :-).
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
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.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.