Overview

Robot Framework Tutorial 2016 – Remote Server Keywords in Java

No Comments

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

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).

package de.codecentric.robot.sample.keywords;
 
import org.robotframework.javalib.annotation.ArgumentNames;
import org.robotframework.javalib.annotation.RobotKeyword;
import org.robotframework.javalib.annotation.RobotKeywords;
 
@RobotKeywords
public class SampleKeywords {
 
    @RobotKeyword("Print Message")
    @ArgumentNames({"message"})
    public void printMessage(String message) {
        System.out.println(message);
    }
}

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.

package de.codecentric.robot.sample;
 
import org.robotframework.javalib.library.AnnotationLibrary;
import org.robotframework.remoteserver.RemoteServer;
 
public class SampleRemoteLibrary extends AnnotationLibrary {
 
    public SampleRemoteLibrary() {
        super("de/codecentric/robot/sample/keywords/*.class");
    }
 
    @Override
    public String getKeywordDocumentation(String keywordName) {
        if (keywordName.equals("__intro__")) {
            return "Intro";
        }
 
        return super.getKeywordDocumentation(keywordName);
    }
 
    public static void main(String[] args) throws Exception {
        RemoteServer.configureLogging();
        RemoteServer server = new RemoteServer();
        server.addLibrary(SampleRemoteLibrary.class, 8270);
        server.start();
    }
}

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 :-).

Comment

Your email address will not be published. Required fields are marked *