Further extend the testing capabilities of the robot framework using the Remote interface library

Introduction:

The four-layer structure of the ROBOT framework has greatly improved its extensibility. We can use its extensive library of extensions to do most of the testing work. But in the following two cases, only four layers of structure is not good to make:

1. Some complex tests may span multiple physical machines, and some test libraries must also be deployed on the systems under test.

2. A test will use multiple libraries, but some can only be run with Jybot, and some can only be run with Pybot (this is a common case).

The principle of Remote library interface:

To address these two challenges, the Robot Framework provides remote library interface technology (interface).

What is remote library interface technology? In fact, it is very simple, remote library interface is the original test library into three parts

Part of it we can call him remote library, the second part is called remote server, and the third part is the real test library. The test library provides a true test function, which is wrapped by a remote server and accessed by the remote repository via the XML-RPC Protocol (see). The idea of its implementation is plainly the proxy mode in the design pattern.

The benefits of doing so are obvious. Remote library as long as the XML-RPC protocol can access the remote server, the way the remote server is implemented does not matter, which means we can use any of the advanced language support XML-RPC for RF write extension library , check the data, Almost all high-level languages support this ancient simple protocol.

To use the Remote interface library:

As mentioned above, RF put the original test library into the remote library, remote server, test library three parts. So how can the original test library be transformed? We have to have a server first. Currently, RF provides PYTHON,RUBY,.NET,JAVA,PERL and Clojure servers. In this link you can download them:

Http://code.google.com/p/robotframework/wiki/RemoteLibrary

After downloading to the remote server, the package works and then calls the remote library in RF.

Here I use the Python example to explain in detail how to use the remote library.

Ø Download Server

Python's server implementation is very simple, with only one file, a few kilobytes in size.

We can download it at this URL:

http://robotframework.googlecode.com/hg/tools/remoteserver/robotremoteserver.py

Ø Retrofit Test Library

Some people will ask, not using proxy mode? Why reform the test library? Should not transform the server to do proxy?

In fact, anyone can transform. But Python has a very good feature of being able to dynamically determine behavior based on whether it is called directly or indirectly. With this, we can transform an existing test library so that it can be used as a local repository and can be called remotely.

Take Robotframework's built-in string library for example:

First we copy the robotremoteserver.py into the same directory as the string.py, then open the source code of the string library and add the following code at the end:

if __name__ = = ' __main__ ':

Importsys

Fromrobotremoteserver Import Robotremoteserver

Robotremoteserver (String (), *sys.argv[1:])

Save. Then a remote server wraps the string library.

Analyzing the code, we just instantiate a remote server and pass the string class as a parameter.

In fact, we can also set the remote server IP and port number here.

if __name__ = = ' __main__ ':

Importsys

Fromrobotremoteserver Import Robotremoteserver

Robotremoteserver (String (), ' 172.22.xx.xx ', ' 8081 ' *sys.argv[1:])

If not set, it can also be set when running this server.

Ø Run Remote Library

In command-line mode, enter the directory where the string.py is located, executing

string.py 172.22.22.42 8081

At this point, RF will tell you that a remote server wrapped in the test library has been started.

Ø call remote library in RF

First we refer to the remote library, which can be used directly, without any distinction from using a local library.

The following is a script to test the remote string library.

Settings * * *

Library Remote 172.22.22.42:8081 with NAME RString

Test Cases * * *

Testfetch

${STR} fetchfromleft I Love Test 5

The script refers to the remote library we built just now, all the remote library names are called remote, different is just the back of the IP address and port number, we can also use the Withname keyword to give it an alias, This is to solve the problem of having the same keyword in multiple remote libraries (you can differentiate it by using a keyword before the namespace)

The following link is a description of the remote library interface implemented by other high-level languages, as the principle is similar, it is no longer one by one explained.

java:http://code.google.com/p/jrobotremoteserver/

perl:http://code.google.com/p/plrobotremoteserver/

. net:http://code.google.com/p/sharprobotremoteserver/

Summary:

With the remote library interface technology, we can almost glue all the test tools that provide the interface, and the outside report a skin. We can also write test libraries in a variety of high-level languages. However, it is worth noting that some servers are not perfect, such as the Java Remote Library interface can not be properly passed exception, guessing that some complex objects are not good through the XML-RPC protocol serialization, feel this can be wrapped another layer of skin:)

Use the Remote interface library to further extend the testing capabilities of the robot framework