Install python-docutils

Installing python-docutils package on Ubuntu 12.04 (Precise Pangolin) is as easy as running the following command on terminal:

sudo apt-get update

sudo apt-get install python-docutils

Using code blocks

reStructuredText documents can contain code examples in so called code blocks. When these documents are compiled into HTML or other formats, the code blocks are syntax highlighted using Pygments. In standard reST code blocks are started using the code directive, but Sphinx uses code-block or sourcecode instead. The name of the programming language in the code block is given as an argument to the directive. For example, following code blocks contain Python and Robot Framework examples, respectively:

.. code:: python

def example_keyword():

print 'Hello, world!'

.. code:: robotframework

* Test Cases *

Example Test

Example Keyword

When Robot Framework parses reStructuredText files, it first searches for possible code, code-block or sourcecode blocks containing Robot Framework test data. If such code blocks are found, data they contain is written into an in-memory file and executed. All data outside the code blocks is ignored.

The test data in the code blocks must be defined using the plain text format. As the example below illustrates, both space and pipe separated variants are supported:

Example


This text is outside code blocks and thus ignored.

.. code:: robotframework

* Settings *

Library OperatingSystem

* Variables *

${MESSAGE} Hello, world!

* Test Cases *

My Test

[Documentation] Example test

Log ${MESSAGE}

My Keyword /tmp

Another Test

Should Be Equal ${MESSAGE} Hello, world!

Also this text is outside code blocks and ignored. Above block used

the space separated plain text format and the block below uses the pipe

separated variant.

.. code:: robotframework

| * Keyword * | | |

| My Keyword | [Arguments] | ${path} |

| | Directory Should Exist | ${path} |

Note

Escaping using the backslash character works normally in this format. No double escaping is needed like when using reST tables.

Note

Support for test data in code blocks is a new feature in Robot Framework 2.8.2.

Using tables

If a reStructuredText document contains no code blocks with Robot Framework data, it is expected to contain the data in tables similarly as in the HTML format. In this case Robot Framework compiles the document to HTML in memory and parses it exactly like it would parse a normal HTML file.

Robot Framework identifies test data tables based on the text in the first cell and all content outside of the recognized table types is ignored. An example of each of the four test data tables is shown below using both simple table and grid table syntax:

Example


This text is outside tables and thus ignored.

============ ================ ======= =======

Setting Value Value Value

============ ================ ======= =======

Library OperatingSystem

============ ================ ======= =======

============ ================ ======= =======

Variable Value Value Value

============ ================ ======= =======

${MESSAGE} Hello, world!

============ ================ ======= =======

============= ================== ============ =============

Test Case Action Argument Argument

============= ================== ============ =============

My Test [Documentation] Example test

\ Log ${MESSAGE}

\ My Keyword /tmp

\

Another Test Should Be Equal ${MESSAGE} Hello, world!

============= ================== ============ =============

Also this text is outside tables and ignored. Above tables are created

using the simple table syntax and the table below uses the grid table

approach.

+-------------+------------------------+------------+------------+

| Keyword | Action | Argument | Argument |

+-------------+------------------------+------------+------------+

| My Keyword | [Arguments] | ${path} | |

+-------------+------------------------+------------+------------+

| | Directory Should Exist | ${path} | |

+-------------+------------------------+------------+------------+

Note

Empty cells in the first column of simple tables need to be escaped. The above example uses \ but .. could also be used.

Note

Because the backslash character is an escape character in reST, specifying a backslash so that Robot Framework will see it requires escaping it with an other backslash like \. For example, a new line character must be written like \n. Because the backslash is used for escaping also in Robot Framework data, specifying a literal backslash when using reST tables requires double escaping like c:\\temp.

Generating HTML files based on reST files every time tests are run obviously adds some overhead. If this is a problem, it can be a good idea to convert reST files to HTML using external tools separately, and let Robot Framework use the generated files only.

Editing and encoding

Test data in reStructuredText files can be edited with any text editor, and many editors also provide automatic syntax highlighting for it. reST format is not supported by RIDE, though.

Robot Framework requires reST files containing non-ASCII characters to be saved using UTF-8 encoding.

Syntax errors in reST source files

If a reStructuredText document is not syntactically correct (a malformed table for example), parsing it will fail and no test cases can be found from that file. When executing a single reST file, Robot Framework will show the error on the console. When executing a directory, such parsing errors will generally be ignored.

2.1.3 Test data tables

Test data is structured in four types of tables listed below. These test data tables are identified by the first cell of the table, and the last column in the table below lists different aliases that can be used as a table name.

Different test data tables
Table name Used for Aliases
Setting table 1) Importing test libraries, resource files and variable files Setting, Settings, Metadata
Variable table Defining variables that can be used elsewhere in the test data Variable, Variables
Test case table Creating test cases from available keywords Test Case, Test Cases
Keyword table Creating user keywords from existing lower-level keywords Keyword, Keywords, User Keyword, User Keywords

2.1.4 Rules for parsing the data

Ignored data

When Robot Framework parses the test data, it ignores:

  • All tables that do not start with a recognized table name in the first cell.
  • Everything else on the first row of a table apart from the first cell.
  • All data before the first table. If the data format allows data between tables, also that is ignored.
  • All empty rows, which means these kinds of rows can be used to make the tables more readable.
  • All empty cells at the end of rows, unless they are escaped.
  • All single backslashes () when not used for escaping.
  • All characters following the hash character (#), when it is the first character of a cell. This means that hash marks can be used to enter comments in the test data.
  • All formatting in the HTML/reST test data.

When Robot Framework ignores some data, this data is not available in any resulting reports and, additionally, most tools used with Robot Framework also ignore them. To add information that is visible in Robot Framework outputs, place it to the documentation or other metadata of test cases or suites, or log it with the BuiltIn keywords Log or Comment.

Handling whitespace

Robot Framework handles whitespace the same way as they are handled in HTML source code:

  • Newlines, carriage returns, and tabs are converted to spaces.
  • Leading and trailing whitespace in all cells is ignored.
  • Multiple consecutive spaces are collapsed into a single space.

In addition to that, non-breaking spaces are replaced with normal spaces. This is done to avoid hard-to-debug errors when a non-breaking space is accidentally used instead of a normal space.

If leading, trailing, or consecutive spaces are needed, they must be escaped. Newlines, carriage returns, tabs, and non-breaking spaces can be created using escape sequences \n, \r, \t, and \xA0 respectively.

Escaping

The escape character in Robot Framework test data is the backslash () and additionally built-in variables ${EMPTY} and ${SPACE} can often be used for escaping. Different escaping mechanisms are discussed in the sections below.

Escaping special characters

The backslash character can be used to escape special characters so that their literal values are used.

Escaping special characters
Character Meaning Examples
$ Dollar sign, never starts a scalar variable. ${notvar}
\@ At sign, never starts a list variable. \@{notvar}
\% Percent sign, never starts an environment variable. \%{notvar}
# Hash sign, never starts a comment. # not comment
\= Equal sign, never part of named argument syntax. not\=named
\ Pipe character, not a separator in the pipe separated format. Run ps \ grep xxx
\ Backslash character, never escapes anything. c:\temp, \${var}

Forming escape sequences

The backslash character also allows creating special escape sequences that are recognized as characters that would otherwise be hard or impossible to create in the test data.

Escape sequences
Sequence Meaning Examples
\n Newline character. first line\n2nd line
\r Carriage return character text\rmore text
\t Tab character. text\tmore text
\xhh Character with hex value hh. null byte: \x00, ä: \xE4
\uhhhh Character with hex value hhhh. snowman: \u2603
\Uhhhhhhhh Character with hex value hhhhhhhh. love hotel: \U0001f3e9

Note

All strings created in the test data, including characters like \x02, are Unicode and must be explicitly converted to byte strings if needed. This can be done, for example, using Convert To Bytes or Encode String To Bytes keywords in BuiltIn and String libraries, respectively, or with something like str(value) or value.encode('UTF-8') in Python code.

Note

If invalid hexadecimal values are used with \x, \u or \U escapes, the end result is the original value without the backslash character. For example, \xAX (not hex) and \U00110000 (too large value) result with xAX and U00110000, respectively. This behavior may change in the future, though.

Note

Built-in variable ${\n} can be used if operating system dependent line terminator is needed (\r\n on Windows and \n elsewhere).

Note

Possible un-escaped whitespace character after the \n is ignored. This means that two lines\nhere and two lines\n here are equivalent. The motivation for this is to allow wrapping long lines containing newlines when using the HTML format, but the same logic is used also with other formats. An exception to this rule is that the whitespace character is not ignored inside the extended variable syntax.

Note

\x, \u and \U escape sequences are new in Robot Framework 2.8.2.

Prevent ignoring empty cells

If empty values are needed as arguments for keywords or otherwise, they often need to be escaped to prevent them from being ignored. Empty trailing cells must be escaped regardless of the test data format, and when using the space separated format all empty values must be escaped.

Empty cells can be escaped either with the backslash character or with built-in variable ${EMPTY}. The latter is typically recommended as it is easier to understand. An exception to this recommendation is escaping the indented cells in for loops with a backslash when using the space separated format. All these cases are illustrated in the following examples first in HTML and then in the space separated plain text format:

Test Case Action Argument Argument Argument
Using backslash Do Something first arg \
Using ${EMPTY} Do Something first arg ${EMPTY}
Non-trailing empty Do Something second arg # No escaping needed in HTML
For loop :FOR ${var} IN @{VALUES}
Log ${var} # No escaping needed here either

* Test Cases *

Using backslash

Do Something first arg \

Using ${EMPTY}

Do Something first arg ${EMPTY}

Non-trailing empty

Do Something ${EMPTY} second arg # Escaping needed in space separated format

For loop

:FOR ${var} IN @{VALUES}

\ Log ${var} # Escaping needed here too

Prevent ignoring spaces

Because leading, trailing, and consecutive spaces in cells are ignored, they need to be escaped if they are needed as arguments to keywords or otherwise. Similarly as when preventing ignoring empty cells, it is possible to do that either using the backslash character or using built-in variable${SPACE}.

Escaping spaces examples
Escaping with backslash Escaping with ${SPACE} Notes
\ leading space ${SPACE}leading space
trailing space \ trailing space${SPACE} Backslash must be after the space.
\ \ ${SPACE} Backslash needed on both sides.
consecutive \ \ spaces consecutive${SPACE * 3}spaces Using extended variable syntax.

As the above examples show, using the ${SPACE} variable often makes the test data easier to understand. It is especially handy in combination with the extended variable syntax when more than one space is needed.

Dividing test data to several rows

If there is more data than readily fits a row, it possible to use ellipsis (...) to continue the previous line. In test case and user keyword tables, the ellipsis must be preceded by at least one empty cell. In settings and variable tables, it can be placed directly under the setting or variable name. In all tables, all empty cells before the ellipsis are ignored.

Additionally, values of settings that take only one value (mainly documentations) can be split to several columns. These values will be then catenated together with spaces when the test data is parsed. Starting from Robot Framework 2.7, documentation and test suite metadata split into multiple rows will be catenated together with newlines.

All the syntax discussed above is illustrated in the following examples. In the first three tables test data has not been split, and the following three illustrate how fewer columns are needed after splitting the data to several rows.

Test data that has not been split
Setting Value Value Value Value Value Value
Default Tags tag-1 tag-2 tag-3 tag-4 tag-5 tag-6
Variable Value Value Value Value Value Value
@{LIST} this list has quite many items
Test Case Action Argument Arg Arg Arg Arg Arg Arg
Example [Documentation] Documentation for this test case.\n This can get quite long...
[Tags] t-1 t-2 t-3 t-4 t-5
Do X one two three four five six
${var} = Get X 1 2 3 4 5 6
Test data split to several rows
Setting Value Value Value
Default Tags tag-1 tag-2 tag-3
... tag-4 tag-5 tag-6
Variable Value Value Value
@{LIST} this list has
... quite many items
Test Case Action Argument Argument Argument
Example [Documentation] Documentation for this test case.
... This can get quite long...
[Tags] t-1 t-2 t-3
... t-4 t-5
Do X one two three
... four five six
${var} = Get X 1 2
... 3 4
... 5 6

results matching ""

    No results matching ""