Skip to main content

Robot Framework remote server implemented with Python

Project description

Robot Framework remote servers allow hosting test libraries on different processes or machines than Robot Framework itself is running on. This project implements a generic remote server using the Python programming language. See the remote library interface documentation for more information about the remote interface in general as well as for a list of remote server implementations in other programming languages.

This project is hosted on GitHub and downloads are available on PyPI.

Supported Python versions

This remote server is implemented with Python and supports also Jython (JVM), IronPython (.NET) and PyPy. Remote server version 1.1 supports Python 2.6, 2.7 and 3.3-3.9. Remote server version 1.1.1 supports Python 3.10 and 3.11 as well.

Supported library APIs

Starting from the remote server version 1.1, Robot Framework’s static, hybrid and dynamic library APIs are all supported. This includes setting custom name and tags for keywords using the robot.api.deco.keyword. Earlier remote server versions support only the static and hybrid APIs and do not support the keyword decorator at all.

For most parts these APIs work exactly like when using with Robot Framework normally. The main limitation is that logging using robot.api.logger or Python’s logging module is currently not supported.

Installation

The easiest installation approach is using pip:

pip install robotremoteserver

Alternatively you can download the source distribution from PyPI, extract it and install the remote server using:

python setup.py install

Remote server configuration

The remote server is implemented as a class RobotRemoteServer and it accepts the following configuration parameters when it is initialized:

Argument

Default

Explanation

library

Test library instance or module to host. Mandatory argument.

host

'127.0.0.1'

Address to listen. Use '0.0.0.0' to listen to all available IPv4 interfaces.

port

8270

Port to listen. Use 0 to select a free port automatically. Can be given as an integer or as a string. The default port 8270 is registered by IANA for remote server usage.

port_file

None

File to write the port that is used. None (default) means no such file is written.

allow_stop

'DEPRECATED'

Deprecated since version 1.1. Use allow_remote_stop instead.

serve

True

If True, start the server automatically and wait for it to be stopped. If False, server can be started using the serve method. New in version 1.1.

allow_remote_stop

True

Allow/disallow stopping the server remotely using Stop Remote Server keyword and stop_remote_server XML-RPC method. New in version 1.1.

Starting remote server

The remote server can be started simply by creating an instance of the server and passing a test library instance or module to it:

from robotremoteserver import RobotRemoteServer
from mylibrary import MyLibrary

RobotRemoteServer(MyLibrary())

By default the server listens to address 127.0.0.1 and port 8270. As discussed above, the remote server accepts various configuration parameters. Some of them are used by this example:

from robotremoteserver import RobotRemoteServer
from examplelibrary import ExampleLibrary

RobotRemoteServer(ExampleLibrary(), host='10.0.0.42', port=0,
                  port_file='/tmp/remote-port.txt')

Starting from version 1.1, the server can be initialized without starting it by using the argument serve=False. The server can then started afterwards by calling its serve method explicitly. This example is functionally equivalent to the example above:

from robotremoteserver import RobotRemoteServer
from examplelibrary import ExampleLibrary

server = RobotRemoteServer(ExampleLibrary(), host='10.0.0.42', port=0,
                           port_file='/tmp/remote-port.txt', serve=False)
server.serve()

Starting server on background

The main benefit of separately initializing and starting the server is that it makes it easier to start the server in a background thread. Servers started in a thread work exactly like servers running in the main tread except that stopping the server gracefully using Ctrl-C or signals is not supported automatically. Users must thus register signal handlers separately if needed.

Also this following example is functionally nearly equivalent to the earlier examples except. The main difference is that not all same signals are handled.

import signal
import threading
from examplelibrary import ExampleLibrary
from robotremoteserver import RobotRemoteServer

server = RobotRemoteServer(ExampleLibrary(), port=0, serve=False)
signal.signal(signal.SIGINT, lambda signum, frame: server.stop())
server_thread = threading.Thread(target=server.serve)
server_thread.start()
while server_thread.is_alive():
    server_thread.join(0.1)

Getting active server port

If the server uses the default port 8270 or some other port is given explicitly when configuring the server, you obviously know which port to use when connecting the server. When using the port 0, the server selects a free port automatically, but there are various ways how to find out the actual port:

  • Address and port that are used are printed into the console where the server is started.

  • If port_file argument is used, the server writes the port into the specified file where other tools can easily read it. Starting from the remote server version 1.1, the server removes the port file automatically when the server is stopped.

  • Starting from the version 1.1, the server has activate method that can be called to activate the server without starting it. This method returns the port that the server binds and also sets it available via the attributes discussed below.

  • A started or actived server instance has server_address attribute that contains the address and the port as a tuple. Starting from the version 1.1 there is also server_port attribute that contains just the port as an integer.

Stopping remote server

The remote server can be gracefully stopped using several different methods:

  • Hitting Ctrl-C on the console where the server is running. Not supported automatically if the server is started on a background thread.

  • Sending the process SIGINT, SIGTERM, or SIGHUP signal. Does not work on Windows and not supported if the server is started on a background thread.

  • Using the``Stop Remote Server`` keyword. Can be disabled by using allow_remote_stop=False when initializing the server.

  • Using the stop_remote_server function in the XML-RPC interface. Can be disabled with the allow_remote_stop=False initialization parameter.

  • Running python -m robotremoteserver stop [uri] which uses the aforementioned stop_remote_server XML-RPC function internally. Can be disabled with the allow_remote_stop=False initialization parameter.

  • Using the stop_remote_server function provided by the robotremoteserver module similarly as when testing is server running. Uses the stop_remote_server XML-RPC function internally and can be disabled with the allow_remote_stop=False initialization parameter.

  • Calling the stop method of the running server instance. Mainly useful when running the server on background.

Testing is server running

Starting from the version 1.0.1, the robotremoteserver module supports testing is a remote server running. This can be accomplished by running the module as a script with test argument and an optional URI:

$ python -m robotremoteserver test
Remote server running at http://127.0.0.1:8270.
$ python -m robotremoteserver test http://10.0.0.42:57347
No remote server running at http://10.0.0.42:57347.

Starting from the version 1.1, the robotremoteserver module contains function test_remote_server that can be used programmatically:

from robotremoteserver import test_remote_server

if test_remote_server('http://localhost:8270'):
    print('Remote server running!')

The robotremoteserver module can be also used to stop a remote server by using stop argument on the command line or by using the stop_remote_server function programmatically. Testing and stopping should work also with other Robot Framework remote server implementations.

Listing keywords and viewing documentation

Using the built-in Libdoc tool you can list the keywords available on the server:

$ python -m robot.libdoc Remote::http://127.0.0.1:8270 list
Count Items In Directory
Stop Remote Server
Strings Should Be Equal

It is also possible to show the documentation on the command line by using argument show. HTML documentation can be created by providing name of an output file:

$ python -m robot.libdoc Remote::http://127.0.0.1:8270 MyLibrary.html
/path/to/MyLibrary.html

Example

The remote server project contains an example that can be studied and also executed once the library is installed. You can get the example by cloning the project on GitHub, and it is also included in the source distribution available on PyPI.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

robotremoteserver-1.1.1.tar.gz (20.2 kB view details)

Uploaded Source

Built Distribution

robotremoteserver-1.1.1-py2.py3-none-any.whl (15.2 kB view details)

Uploaded Python 2 Python 3

File details

Details for the file robotremoteserver-1.1.1.tar.gz.

File metadata

  • Download URL: robotremoteserver-1.1.1.tar.gz
  • Upload date:
  • Size: 20.2 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/4.0.2 CPython/3.8.10

File hashes

Hashes for robotremoteserver-1.1.1.tar.gz
Algorithm Hash digest
SHA256 378c5a93275f1277369426aba3c9cdfafbed75f9e926ed7ba54c92c948b29411
MD5 dda055599e8cdf540370e3d21b2f7f11
BLAKE2b-256 ab7fca08c86a23bf4ea260ba640855db95e6daf044942e2e51bda0d59ed81573

See more details on using hashes here.

File details

Details for the file robotremoteserver-1.1.1-py2.py3-none-any.whl.

File metadata

File hashes

Hashes for robotremoteserver-1.1.1-py2.py3-none-any.whl
Algorithm Hash digest
SHA256 a344051d4e2bf435e0970365d4051cda13100395e072ff88cb740f9c363206bf
MD5 cbdc4782d53875957485e274c0438f19
BLAKE2b-256 ce77532abf69fe4107cf0dea47c84816cb4ed65e15f376cee93690fe89b0ec78

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page