Robot Framework Non-Critical Thinking Definition

These instructions cover installing and uninstalling Robot Framework and its preconditions on different operating systems. If you already have pip installed, it is enough to run:

1.3.1   Introduction

Robot Framework is implemented with Python and supports also Jython (JVM), IronPython (.NET) and PyPy. Before installing the framework, an obvious precondition is installing at least one of these interpreters.

Different ways to install Robot Framework itself are listed below and explained more thoroughly in the subsequent sections.

Installing with pip

Using pip is the recommended way to install Robot Framework. As the standard Python package manager it is included in the latest Python, Jython and IronPython versions. If you already have pip available, you can simply execute:

pip install robotframework
Installing from source
This approach works regardless the operating system and the Python interpreter used. You can get the source code either by downloading a source distribution from PyPI and extracting it, or by cloning the GitHub repository .
Standalone JAR distribution
If running tests with Jython is enough, the easiest approach is downloading the standalone from Maven central. The JAR distribution contains both Jython and Robot Framework and thus only requires having Java installed.
Manual installation
If you have special needs and nothing else works, you can always do a custom manual installation.

Note

Prior to Robot Framework 3.0, there were also separate Windows installers for 32bit and 64bit Python versions. Because Python 2.7.9 and newer contain pip on Windows and Python 3 would have needed two more installers, it was decided that Windows installers are not created anymore. The recommend installation approach also on Windows is using pip.

1.3.2   Preconditions

Robot Framework is supported on Python (both Python 2 and Python 3), Jython (JVM) and IronPython (.NET) and PyPy. The interpreter you want to use should be installed before installing the framework itself.

Which interpreter to use depends on the needed test libraries and test environment in general. Some libraries use tools or modules that only work with Python, while others may use Java tools that require Jython or need .NET and thus IronPython. There are also many tools and libraries that run fine with all interpreters.

If you do not have special needs or just want to try out the framework, it is recommended to use Python. It is the most mature implementation, considerably faster than Jython or IronPython (especially start-up time is faster), and also readily available on most UNIX-like operating systems. Another good alternative is using the standalone JAR distribution that only has Java as a precondition.

Python 2 vs Python 3

Python 2 and Python 3 are mostly the same language, but they are not fully compatible with each others. The main difference is that in Python 3 all strings are Unicode while in Python 2 strings are bytes by default, but there are also several other backwards incompatible changes. The last Python 2 release is Python 2.7 that was released in 2010 and will be supported until 2020. See Should I use Python 2 or 3? for more information about the differences, which version to use, how to write code that works with both versions, and so on.

Robot Framework 3.0 is the first Robot Framework version to support Python 3. It supports also Python 2, and the plan is to continue Python 2 support as long as Python 2 itself is officially supported. We hope that authors of the libraries and tools in the wider Robot Framework ecosystem also start looking at Python 3 support now that the core framework supports it.

Python installation

On most UNIX-like systems such as Linux and OS X you have Python installed by default. If you are on Windows or otherwise need to install Python yourself, a good place to start is http://python.org. There you can download a suitable installer and get more information about the installation process and Python in general.

Robot Framework 3.0 supports Python 2.6, 2.7, 3.3 and newer, but the plan is to drop Python 2.6 support in RF 3.1. If you need to use older versions, Robot Framework 2.5-2.8 support Python 2.5 and Robot Framework 2.0-2.1 support Python 2.3 and 2.4.

On Windows it is recommended to install Python to all users and to run the installer as an administrator. Additionally, environment variable must not be set.

After installing Python, you probably still want to configure PATH to make Python itself as well as the and runner scripts executable on the command line.

Tip

Latest Python Windows installers allow setting as part of the installation. This is disabled by default, but can be enabled on the screen.

Jython installation

Using test libraries implemented with Java or that use Java tools internally requires running Robot Framework on Jython, which in turn requires Java Runtime Environment (JRE) or Java Development Kit (JDK). Installing either of these Java distributions is out of the scope of these instructions, but you can find more information, for example, from http://java.com.

Installing Jython is a fairly easy procedure, and the first step is getting an installer from http://jython.org. The installer is an executable JAR package, which you can run from the command line like . Depending on the system configuration, it may also be possible to just double-click the installer.

Robot Framework 3.0 supports Jython 2.7 which requires Java 7 or newer. If older Jython or Java versions are needed, Robot Framework 2.5-2.8 support Jython 2.5 (requires Java 5 or newer) and Robot Framework 2.0-2.1 support Jython 2.2.

After installing Jython, you probably still want to configure PATH to make Jython itself as well as the and runner scripts executable on the command line.

IronPython installation

IronPython allows running Robot Framework on the .NET platform and interacting with C# and other .NET languages and APIs. Only IronPython 2.7 is supported.

When using IronPython, an additional dependency is installing elementtree module 1.2.7 preview release. This is required because the module distributed with IronPython is broken. You can install the package by downloading the source distribution, unzipping it, and running on the command prompt in the created directory.

After installing IronPython, you probably still want to configure PATH to make IronPython itself as well as the and runner scripts executable on the command line.

PyPy installation

PyPy is an alternative implementation of the Python language with both Python 2 and Python 3 compatible versions available. Its main advantage over the standard Python implementation is that it can be faster and use less memory, but this depends on the context where and how it is used. If execution speed is important, at least testing PyPY is probably a good idea.

Installing PyPy is a straightforward procedure and you can find both installers and installation instructions at http://pypy.org. After installation you probably still want to configure PATH to make PyPy itself as well as the and runner scripts executable on the command line.

Configuring

The environment variable lists locations where commands executed in a system are searched from. To make using Robot Framework easier from the command prompt, it is recommended to add the locations where the runner scripts are installed into the . It is also often useful to have the interpreter itself in the to make executing it easy.

When using Python on UNIX-like machines both Python itself and scripts installed with should be automatically in the and no extra actions needed. On Windows and with other interpreters the must be configured separately.

Tip

Latest Python Windows installers allow setting as part of the installation. This is disabled by default, but can be enabled on the screen. It will add both the Python installation directory and the Scripts directory to the .

What directories to add to

What directories you need to add to the depends on the interpreter and the operating system. The first location is the installation directory of the interpreter (e.g. C:\Python27) and the other is the location where scripts are installed with that interpreter. Both Python and IronPython install scripts to Scripts directory under the installation directory on Windows (e.g. C:\Python27\Scripts) and Jython uses bin directory regardless the operating system (e.g. C:\jython2.7.0\bin).

Notice that the Scripts and bin directories may not be created as part of the interpreter installation, but only later when Robot Framework or some other third party module is installed.

Setting on Windows

On Windows you can configure by following the steps below. Notice that the exact setting names may be different on different Windows versions, but the basic approach should still be the same.

  1. Open . There are and , and the difference between them is that user variables affect only the current users, whereas system variables affect all users.
  2. To edit an existing value, select and add at the end of the value (e.g. ). Note that the semicolons () are important as they separate the different entries. To add a new value, select and set both the name and the value, this time without the leading semicolon.
  3. Exit the dialog with to save the changes.
  4. Start a new command prompt for the changes to take effect.

Notice that if you have multiple Python versions installed, the executed or runner script will always use the one that is first in the regardless under what Python version that script is installed. To avoid that, you can always execute the installed robot module directly like .

Notice also that you should not add quotes around directories you add into the (e.g. ). Quotes can cause problems with Python programs and they are not needed in this context even if the directory path would contain spaces.

Setting on UNIX-like systems

On UNIX-like systems you typically need to edit either some system wide or user specific configuration file. Which file to edit and how depends on the system, and you need to consult your operating system documentation for more details.

Setting

If you are installing with pip and are behind a proxy, you need to set the environment variable. It is needed both when installing pip itself and when using it to install Robot Framework and other Python packages.

How to set the depends on the operating system similarly as configuring PATH. The value of this variable must be an URL of the proxy, for example, .

1.3.3   Installing with pip

The standard Python package manager is pip, but there are also other alternatives such as Buildout and easy_install. These instructions only cover using pip, but other package managers ought be able to install Robot Framework as well.

Latest Python, Jython, IronPython and PyPy versions contain pip bundled in. Which versions contain it and how to possibly activate it is discussed in sections below. See pip project pages if for the latest installation instructions if you need to install it.

Note

Only Robot Framework 2.7 and newer can be installed using pip. If you need an older version, you must use other installation approaches.

Installing pip for Python

Starting from Python 2.7.9, the standard Windows installer by default installs and activates pip. Assuming you also have configured PATH and possibly set https_proxy, you can run right after Python installation. With Python 3.4 and newer pip is officially part of the interpreter and should be automatically available.

Outside Windows and with older Python versions you need to install pip yourself. You may be able to do it using system package managers like Apt or Yum on Linux, but you can always use the manual installation instructions found from the pip project pages.

If you have multiple Python versions with pip installed, the version that is used when the command is executed depends on which pip is first in the PATH. An alternative is executing the module using the selected Python version directly:

python -m pip install robotframework python3 -m pip install robotframework

Installing pip for Jython

Jython 2.7 contain pip bundled in, but it needs to be activated before using it by running the following command:

Jython installs its pip into <JythonInstallation>/bin directory. Does running actually use it or possibly some other pip version depends on which pip is first in the PATH. An alternative is executing the module using Jython directly:

jython -m pip install robotframework

Installing pip for IronPython

IronPython contains bundled pip starting from version 2.7.5. Similarly as with Jython, it needs to be activated first:

ipy -X:Frames -m ensurepip

Notice that with IronPython command line option is needed both when activating and when using pip.

IronPython installs pip into <IronPythonInstallation>/Scripts directory. Does running actually use it or possibly some other pip version depends on which pip is first in the PATH. An alternative is executing the module using IronPython directly:

ipy -X:Frames -m pip install robotframework

IronPython versions prior to 2.7.5 do not officially support pip.

Installing pip for PyPy

Also PyPy contains pip bundled in. It is not activated by default, but it can be activated similarly as with the other interpreters:

pypy -m ensurepip pypy3 -m ensurepip

If you have multiple Python versions with pip installed, the version that is used when the command is executed depends on which pip is first in the PATH. An alternative is executing the module using PyPy directly:

Using pip

Once you have pip installed, and have set https_proxy if you are behind a proxy, using pip on the command line is very easy. The easiest way to use pip is by letting it find and download packages it installs from the Python Package Index (PyPI), but it can also install packages downloaded from the PyPI separately. The most common usages are shown below and pip documentation has more information and examples.

# Install the latest version pip install robotframework # Upgrade to the latest version pip install --upgrade robotframework # Install a specific version pip install robotframework==2.9.2 # Install separately downloaded package (no network connection needed) pip install robotframework-3.0.tar.gz # Uninstall pip uninstall robotframework

Notice that pip 1.4 and newer will only install stable releases by default. If you want to install an alpha, beta or release candidate, you need to either specify the version explicitly or use the --pre option:

# Install 3.0 beta 1 pip install robotframework==3.0b1 # Upgrade to the latest version even if it is a pre-release pip install --pre --upgrade robotframework

Notice that on Windows pip, by default, does not recreate robot.bat and rebot.bat start-up scripts if the same Robot Framework version is installed multiple times using the same Python version. This mainly causes problems when using virtual environments, but is something to take into account also if doing custom installations using pip. A workaround if using the option like . Alternatively it is possible to ignore the start-up scripts altogether and just use and commands instead.

1.3.4   Installing from source

This installation method can be used on any operating system with any of the supported interpreters. Installing from source can sound a bit scary, but the procedure is actually pretty straightforward.

Getting source code

You typically get the source by downloading a source distribution from PyPI as a package. Once you have downloaded the package, you need to extract it somewhere and, as a result, you get a directory named . The directory contains the source code and a script needed for installing it.

An alternative approach for getting the source code is cloning project's GitHub repository directly. By default you will get the latest code, but you can easily switch to different released versions or other tags.

Installation

Robot Framework is installed from source using Python's standard script. The script is in the directory containing the sources and you can run it from the command line using any of the supported interpreters:

python setup.py install jython setup.py install ipy setup.py install pypy setup.py install

The script accepts several arguments allowing, for example, installation into a non-default location that does not require administrative rights. It is also used for creating different distribution packages. Run for more details.

1.3.5   Standalone JAR distribution

Robot Framework is also distributed as a standalone Java archive that contains both Jython and Robot Framework and only requires Java a dependency. It is an easy way to get everything in one package that requires no installation, but has a downside that it does not work with the normal Python interpreter.

The package is named and it is available on the Maven central. After downloading the package, you can execute tests with it like:

java -jar robotframework-3.0.jar mytests.robot java -jar robotframework-3.0.jar --variable name:value mytests.robot

If you want to post-process outputs using Rebot or use other built-in supporting tools, you need to give the command name , , or as the first argument to the JAR file:

java -jar robotframework-3.0.jar rebot output.xml java -jar robotframework-3.0.jar libdoc MyLibrary list

For more information about the different commands, execute the JAR without arguments.

In addition to the Python standard library and Robot Framework modules, the standalone JAR versions starting from 2.9.2 also contain the PyYAML dependency needed to handle yaml variable files.

1.3.6   Manual installation

If you do not want to use any automatic way of installing Robot Framework, you can always install it manually following these steps:

  1. Get the source code. All the code is in a directory (a package in Python) called robot. If you have a source distribution or a version control checkout, you can find it from the src directory, but you can also get it from an earlier installation.
  2. Copy the source code where you want to.
  3. Decide how to run tests.

1.3.7   Verifying installation

After a successful installation, you should be able to execute the created runner scripts with --version option and get both Robot Framework and interpreter versions as a result:

$ robot --version Robot Framework 3.0 (Python 2.7.10 on linux2) $ rebot --version Rebot 3.0 (Python 2.7.10 on linux2)

If running the runner scripts fails with a message saying that the command is not found or recognized, a good first step is double-checking the PATH configuration. If that does not help, it is a good idea to re-read relevant sections from these instructions before searching help from the Internet or as asking help on robotframework-users mailing list or elsewhere.

Where files are installed

When an automatic installer is used, Robot Framework source code is copied into a directory containing external Python modules. On UNIX-like operating systems where Python is pre-installed the location of this directory varies. If you have installed the interpreter yourself, it is normally Lib/site-packages under the interpreter installation directory, for example, C:\Python27\Lib\site-packages. The actual Robot Framework code is in a directory named robot.

Robot Framework runner scripts are created and copied into another platform-specific location. When using Python on UNIX-like systems, they normally go to /usr/bin or /usr/local/bin. On Windows and with Jython and IronPython, the scripts are typically either in Scripts or bin directory under the interpreter installation directory.

1.3.8   Uninstallation

The easiest way to uninstall Robot Framework is using pip:

pip uninstall robotframework

A nice feature in pip is that it can uninstall packages even if they are installed from the source. If you do not have pip available or have done a manual installation to a custom location, you need to find where files are installed and remove them manually.

If you have set PATH or configured the environment otherwise, you need to undo those changes separately.

1.3.9   Upgrading

If you are using pip, upgrading to a new version requires either specifying the version explicitly or using the --upgrade option. If upgrading to a preview release, --pre option is needed as well.

# Upgrade to the latest stable version. This is the most common method. pip install --upgrade robotframework # Upgrade to the latest version even if it would be a preview release. pip install --upgrade --pre robotframework # Upgrade to the specified version. pip install robotframework==2.9.2

When using pip, it automatically uninstalls previous versions before installation. If you are installing from source, it should be safe to just install over an existing installation. If you encounter problems, uninstallation before installation may help.

When upgrading Robot Framework, there is always a change that the new version contains backwards incompatible changes affecting existing tests or test infrastructure. Such changes are very rare in minor versions like 2.8.7 or 2.9.2, but more common in major versions like 2.9 and 3.0. Backwards incompatible changes and deprecated features are explained in the release notes, and it is a good idea to study them especially when upgrading to a new major version.

1.3.10   Executing Robot Framework

Using and scripts

Starting from Robot Framework 3.0, tests are executed using the script and results post-processed with the script:

robot tests.robot rebot output.xml

Both of these scripts are installed as part of the normal installation and can be executed directly from the command line if PATH is set correctly. They are implemented using Python except on Windows where they are batch files.

Older Robot Framework versions do not have the script and the script is installed only with Python. Instead they have interpreter specific scripts , and for test execution and and for post-processing outputs. These scripts still work, but they will be deprecated and removed in the future.

Executing installed module

An alternative way to run tests is executing the installed module or its sub module directly using Python's -m command line option. This is especially useful if Robot Framework is used with multiple Python versions:

python -m robot tests.robot python3 -m robot.run tests.robot jython -m robot tests.robot /opt/jython/jython -m robot tests.robot

The support for approach is a new feature in Robot Framework 3.0, but the older versions support . The latter must also be used with Python 2.6.

Post-processing outputs using the same approach works too, but the module to execute is :

python -m robot.rebot output.xml

Executing installed directory

If you know where Robot Framework is installed, you can also execute the installed robot directory or the run.py file inside it directly:

python path/to/robot/ tests.robot jython path/to/robot/run.py tests.robot

Running the directory is a new feature in Robot Framework 3.0, but the older versions support running the robot/run.py file.

Post-processing outputs using the robot/rebot.py file works the same way too:

python path/to/robot/rebot.py output.xml

Executing Robot Framework this way is especially handy if you have done a manual installation.

1.3.11   Using virtual environments

Python virtual environments allow Python packages to be installed in an isolated location for a particular system or application, rather than installing all packages into the same global location. Virtual environments can be created using the virtualenv tool or, starting from Python 3.3, using the standard venv module.

Robot Framework in general works fine with virtual environments. The only problem is that when using pip on Windows, and scripts are not recreated by default. This means that if Robot Framework is installed into multiple virtual environments, the and scripts in the latter ones refer to the Python installation in the first virtual environment. A workaround is using the option when installing. Alternatively the start-up scripts can be ignored and and commands used instead.

Introduction

Robot Framework is a Python-based, extensible keyword-driven test automation framework for end-to-end acceptance testing and acceptance-test-driven development (ATDD). It can be used for testing distributed, heterogeneous applications, where verification requires touching several technologies and interfaces.

Why Robot Framework

  • Enables easy-to-use tabular syntax for creating test cases in a uniform way.
  • Provides ability to create reusable higher-level keywords from the existing keywords.
  • Provides easy-to-read result reports and logs in HTML format.
  • Is platform and application independent.
  • Provides a simple library API for creating customized test libraries which can be implemented natively with either Python or Java.
  • Provides a command line interface and XML based output files for integration into existing build infrastructure (continuous integration systems).
  • Provides support for Selenium for web testing, Java GUI testing, running processes, Telnet, SSH, and so on.
  • Supports creating data-driven test cases.
  • Has built-in support for variables, practical particularly for testing in different environments.
  • Provides tagging to categorize and select test cases to be executed.
  • Enables easy integration with source control: test suites are just files and directories that can be versioned with the production code.
  • Provides test-case and test-suite -level setup and teardown.
  • The modular architecture supports creating tests even for applications with several diverse interfaces.

High-level architecture

Robot Framework is a generic, application and technology independent framework. It has a highly modular architecture illustrated in the diagram below. Robot Framework architecture The test data is in simple, easy-to-edit tabular format. When Robot Framework is started, it processes the test data, executes test cases and generates logs and reports. The core framework does not know anything about the target under test, and the interaction with it is handled by test libraries. Libraries can either use application interfaces directly or use lower level test tools as drivers.

Robot Framework Quickstart Guide

This is a guide made to get you up and running quickly! It is not by any means an exhaustive list of the functionality and potential of Robot Framework. It's purpose is to show you how to do the basic stuff in a basic way. This doesn't mean you can't do any useful work with it, quite the opposite. With only the knowledge from this part of the guide, you can create powerful testing suites!

Installation

A precondition for Robot Framework is a recent version of python. For that, Python 2.6 from the EPEL repository was selected and the provided packages are built against it.
Then, you must install the robot_testing repository residing at yum.gridctb.uoa.gr and after that, you can install the packages required. yum install python26 wget http://yum.gridctb.uoa.gr/repository/robot_testing.repo -O /etc/yum.repos.d/robot_testing.repo yum install wxPython-common-gtk2-unicode wxPython2.8-gtk2-unicode yum install robotframework pycrypto paramiko SSHLibrary robotframework-ride

Stuff You Need to Know

Robot Framework is a Python-based, extensible keyword-driven test automation framework. It uses text or html table files, describing the testing steps. These files are comprised of keywords and variables. A keyword is a synonym of a "function" doing "something". A variable is well...a variable!
Tests are created from testsuites. Testsuites are created from tables. The available tables are: (if some things will sound unknown,don't worry,they shall be explained shortly)
  • Settings
    • Used to include libraries, among other things. Can have a Setup and/or a Teardown. Can have Documentation. Can have tags. Can have comments.
  • Variable
    • Used to declare variables.
  • Keyword
    • Used to declare user keywords. Can have Documentation. Can have comments.
  • Test Case
    • Used to create the actual test. Can have a Setup and/or a Teardown. Can have Documentation. Can have tags. Can have comments.
A Setup is a set of things to happen BEFORE the test is executed -e.g.: set up the environment- . A Teardown is a set of thing to be done AFTER the test is executed -e.g.: clean up- . Note that Teardowns are ALWAYS executed, regardless of errors during the test or during the Teardown itself. Also note that Setups/Teardowns must be a single keyword, thus in case of a complex situation, a user level keyword containing all the keywords you want to execute must be created. Setups/Teardowns in the Settings table,will be executed once before and after the testsuite. Setups/Teardowns in the Test Case table, will be execute once before and agter the test case. Tags are used as synonyms. For example, a test case name may be too big or non descriptive. Its tag may have those properties. A test suite or a test case can have multiple tags. Documentation is used to give short descriptions regarding the test element being documented. A user keyword is almost like a test case. For example, if a certain part of the test is executed multiple times,it could be written as a user keyword. User keywords could be imagined as "functions" in the context of imperative programming languages. i.e.: they reduce the clutter, provide better maintainability, they provide better understanding of the algorithm etc. Comments start with # and are used as in any other context. They do not have any other effect. Keywords may or may not take arguments and may or may not return a value. Arguments can be either set explicitly or be assigned first to variables. Return values may be stored in variables. Variables can be either a simple variable (string,number etc) or a list containing multiple variables. Generally, you will use list variables a lot less frequently. Keywords come from libraries. A library is a python module coming with Robot Framework or created by you. The module's functions, are the library's keywords and vice versa. The libraries that come with Robot Framework are: (with their respective original documentation) The Collections library is providing methods for handling Python lists and dictionaries. The rest of the library names are pretty much self explanatory, regarding the keywords/methods/functions they provide. Any library besides BuiltIn, must be explicitly included. This is done in the Settings table (more on that in a bit). Robot framework creates html and xml reports uppon completion. The html reports log which tests passed or failed and how/why. The xml report contains the same data in xml format, to be easily used for post processing. If you want detailed information in your reports,set the command line argument -L TRACE . If you don't want detailed information,set the command line argument -L WARN . Tags main use is to manipulate individual test cases. In this fashion, test cases can be included or excluded from a testsuite execution, or their criticality can be set. (by default all tests are "critical",which means that their failure results in the testsuite's failure) I will show you how to do this later in this part of the guide. You can use any text or html table editor you like for your test cases. In the start, a simple text editor would suffice. Once your testing needs get bigger or you need to experiment further,the RIDE editor is the proposed solution for test case editing. RIDE is a wysiwyg editor providing integration with Robot Framework,syntax highlighting and able to output test cases in simple text or html table format. If you want to create your own library, there are some very basic things you need to remember:
  • You must know python
  • Any method in the python module -NOT starting with underscore(s) that is- can be used as a keyword.
  • The method for setting and reporting failure is through python exceptions. So,supposing that your python method -a.k.a. library keyword- wants to check if a file contains a certain word,it could raise an exception if the words wasn't found. Alternatively, it could return a True/False value, or anything dictated by your app logic and your testing needs.
  • Your custom library can be included like any other library. Most probably, you will/should enter its absolute path.

Examples

All the tests in this section should saved in a simple text file -lets say test.txt- . They can be executed by running: pybot test.txt Once the test is finished, the reports will be available in the current working directory.

Simple Test

This is a simple test,containing only a Test Case table. The cell under "*Test Case*" contains the name of the test case. The cell under "*Action*" contains the action to be taken, described by a keyword. The cells under "*Argument*" cells can be anything else (such as comments or arguments or variables etc). This test checks whether its second string argument "world" is contained within its first string argument "Hello, world!" | *Test Case* | *Action* | *Argument* | *Argument* | | Simple Test | Should Contain | Hello, world! | world |

Include Library

This test shows how to include an extra library. In this case we include the OperatingSystem library. This test creates a file and appends a string to it. | *Setting* | *Value* | | Library | OperatingSystem | | *Test Case* | *Action* | *Argument* | *Argument* | | Simple Test 2 | [Documentation] | Create a temp file | | | | Create File | /tmp/robot_test.txt | | | | Append To File | /tmp/robot_test.txt | 2b || ! 2b |

Set a tag

This is the same as the simple test. This test case demonstrates how a tag can be set. | *Test Case* | *Action* | *Argument* | *Argument* | | | [Tags] | check_str | | | Simple Test | Should Contain | Hello, world! | world |

Use a variable

This is the same as the simple test. This test case illustrates how to set and use a variable. | *Variable* | *Value* | | ${str} | world | | *Test Case* | *Action* | *Argument* | *Argument* | | Simple Test | Should Contain | Hello, world! | ${str} |

Store a return value to a variable

This test illustrates how to store a keyword return value in a variable. This test case reads the time and then it logs it. The value will be present in the report. The value will be present in the report, because of the "Log" keyword. | *Test Case* | *Action* | *Argument* | | Time | ${time}= | Get Time | | | Log | ${time} |

Store multiple return values to variables

This test illustrates how to store a keyword's return values to seperate variables. This test case read the time in hour:minute format and then it logs it. The value will be be present in the report, because of the "Log" keyword. | *Test Case* | *Action* | *Argument* | *Argument* | *Argument* | | Time | ${hour} | ${minute} | Get Time | hour min | | | Log | ${hour}:${minute} | | |

Use Comments

This test is the same as the simple test. It shows the usage of comments | *Test Case* | *Action* | *Argument* | *Argument* | *Argument* | *Argument* | | Simple Test | Should Contain | Hello, world! | world | #I am a comment | I can span multiple cells! |

User Keywords

This is a test demonstrating how to define and use User Keywords. In this test suite, we first import the operating system library, in order to use the "Count Files In Directory" keyword. This keyword's purpose is self explanatory.
Then we create two variables,${path1} and ${path2} which hold two paths in the local filesystem.
Under the Variable Table, there is the Keyword Table. There, we define our own keyword. What it does is that it counts the number of files in the given directory, then reads the time and then logs a message with the results. Note how you can describe that a user keyword takes an argument. A user keyword might take none, one, or more arguments. How we store the return values and how we log a message is already shown in previous examples. Finally, in the Test Case Table, we define some documentation and a tag for our test case. Then we call the user keyword, with the one argument it expects, which is define earlier in the Variables Table. In the end,two messages will be logged in the test's report, saying how many files the paths contained and what time was the measurement taken. | *Setting* | *Value* | | Library | OperatingSystem | | *Variable* | *Value* | | ${path1} | /tmp | | ${path2} | /opt | | *Keyword* | *Action* | *Argument* | *Argument* | | My_KW | [Arguments] | ${path} | | | | ${count}= | Count Files In Directory | ${path} | | | ${time}= | Get Time | | | | Log | At ${time} path ${path} had ${count} items | | | *Test Case* | *Action* | *Argument* | *Argument* | | User KW | [Documentation] | Use a user keyword | | | | [Tags] | user_kw | | | | My KW | ${path1} | | | | My KW | ${path2} | |

Setup and Teardown

This is a test demonstrating how to use a test case setup and teardown. In this, we interchange the contents of two files, with the use of a middle file. In this test suite, first we import the operating system library. Then, we create a user keyword which creates three files. The first two file, have the contents given in the second argument. The third file is left empty. In the test case, we define the setup to the keyword we created, since a single keyword wouldn't suffice -remember, Setups/Teardowns must be a single keyword!- . Also, we define teardown, in which we delete the middle file since we no longer need it at the end of the test. The test case uses a simple algorithm to change the contents of the two files. It first copies the first to the middle, then the second to the first and finally the middle to the second.The contents of the files /tmp/temp_file_one.txt and /tmp/temp_file_two.txt should now be swapped. | *Setting* | *Value* | | Library | OperatingSystem | | *Keyword* | *Action* | *Argument* | *Argument* | | Create Three Files | [Documentation] | Creates three files under /tmp | | | | Create File | /tmp/temp_file_one.txt | File One | | | Create File | /tmp/temp_file_two.txt | File Two | | | Create File | /tmp/temp_file_middle.txt | | | *Test Case* | *Action* | *Argument* | *Argument* | | Set_n_Tear | [Documentation] | Change the contents of two files | | | | [Setup] | Create Three Files | | | | [Teardown] | Remove File | /tmp/temp_file_middle.txt | | | Copy File | /tmp/temp_file_one.txt | /tmp/temp_file_middle.txt | | | Copy File | /tmp/temp_file_two.txt | /tmp/temp_file_one.txt | | | Copy File | /tmp/temp_file_middle.txt | /tmp/temp_file_two.txt |

User Created Library

This is a python module containing an exception (_error) class and a method. The method checks whether a string is contained within a file or not. Save this file in /tmp/test_mod.py class _error(Exception): def __init__(self,string): self.string = string def __str__(self): return str(self.string) def file_should_contain(file_path,search_string): file_path=file_path.encode('ascii') search_string=search_string.encode('ascii') file_as_string=open(file_path).read() if search_string in file_as_string: return True raise _error("The string " + search_string + " wasn't found in file " + file_path) Then,create the following test case. The following test case is designed to fail (in the off chance that your dmesg file indeed contains the string "foobar", then it will of course succeed!) | *Setting* | *Value* | | Library | /tmp/test_mod.py | | *Test Case* | *Action* | *Argument* | *Argument* | | User Lib | [Documentation] | This test uses a user library | | | | File Should Contain | /var/log/dmesg | error | | | File Should Contain | /var/log/dmesg | foobar | All this should be pretty self explanatory be now. We have created a test case which checks if the file given in the first argument, contains the string given in the second argument. Following the python code from above, the first test should probably succeed (it is rather usual for the string "error" to be found in dmesg) and the second should (probably) fail. One thing you should notice is that the keyword name is case insensitive and space insensitive. This is to allow more human readable keywords. Of course there is much more to library building with Robot Framework, but this would get you started!

An EMI Related Example

This is a python module containing an exception class (_error) and a method.
The method provided is "create_proxy", which acts as a keyword-wrapper for the voms-proxy-init command. It utilizes the subprocess module for spawning and tracing new processes (its documentation can be found here: http://docs.python.org/library/subprocess.html), and the shlex module for simple lexical analysis (its documentation can be found here: http://docs.python.org/library/shlex.html). The method accepts two parameters, the user's password and the vo used for the voms extension. Save this file in /tmp/test_mod.py import subprocess , shlex class _error(Exception): def __init__(self,string): self.string = string def __str__(self): return str(self.string) def create_proxy(password,vo): ''' Description: Create a user proxy. Arguments: password,vo for the voms extention. Returns: nothing. ''' com="/usr/bin/voms-proxy-init -pwstdin --voms %s" % vo args = shlex.split(com.encode('ascii')) p = subprocess.Popen( args , shell=False , stderr=subprocess.STDOUT , stdout=subprocess.PIPE , stdin=subprocess.PIPE) p.communicate(input=password) retVal=p.wait() if retVal != 0 : if retVal == 1 : raise _error("Proxy creation failed.Most probably wrong Virtual Organisation was given.") elif retVal == 3 : raise _error("Proxy creation failed.Most probably the password provided was not valid.") else : raise _error("Proxy creation failed.Reason: Unknown.") Then,create the following test case. The following test case doesn't do anything particularly useful, beyond creating a temporary proxy. | *Setting* | *Value* | | Library | /tmp/test_mod.py | | *Test Case* | *Action* | *Argument* | *Argument* | | User Lib | [Documentation] | This test creates a proxy | | | | Create Proxy | p4sSw0rD | dteam |

Cream Testing: A full blown test suite example of Robot Framework

At NKUA we are the developers and maintainers of the new CREAM functionality test suite. It is developed for Robot Framework. The keywords used, beyond the ones provided by the framework itself, are developed by us in an external library. If you want to expand your experiments with Robot Framework or gain a better understanding of how it works, you can find more information here: https://twiki.cern.ch/twiki/bin/view/EMI/CREAMRobotFuncTests.
Also, the package available at the robot_testing repo "cream_test" will install the aforementioned test suite. It depends on lcg-utils, lfc and glite-ce-cream-cli. It is designed to be deployed in an emi-ui, but it can be installed in any relevant environment.

Useful Command Line Options

These are some basic useful command line options. See the appendix for a full list.

Exclude Test Case by Tag

A test case can be excluded from execution, using the -e argument. pybot -e tag_name test.txt

Include Test Case by Tag

The test cases to be executed can be selected, using the -i argument. pybot -i tag_name test.txt

Set Criticality by Tag

Whether a test case is critical to the test suite or not, can be set by using the --critical or --noncritical argument. pybot --critical tag_name text.txt

Set Log Level

The log level of a test suite can be set, using the -L argument. Possible values are FAIL, WARN, INFO, DEBUG, TRACE pybot -L TRACE test.txt

Set Terminal Screen Width

You can set the length of the output shown by Robot Framework by using the -W argument. This is used in order for the output to fit your terminal screen, because Robot Framework's default is rather small. The $COLUMNS variable is rather useful in this situation. pybot -W 125 test.txt

Advanced Guide

The advanced guide for Robot Framework can be found here: https://twiki.cern.ch/twiki/bin/view/EMI/RobotFrameworkAdvancedGuide
-- DimosthenesFioretos - 16-Oct-2011
Copyright &© 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback

0 thoughts on “Robot Framework Non-Critical Thinking Definition”

    -->

Leave a Comment

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