robot.api package

robot.api package exposes the public APIs of Robot Framework.

Unless stated otherwise, the APIs exposed in this package are considered stable, and thus safe to use when building external tools on top of Robot Framework. Notice that all parsing APIs were rewritten in Robot Framework 3.2.

Currently exposed APIs are:

  • logger module for libraries’ logging purposes.
  • deco module with decorators libraries can utilize.
  • exceptions module containing exceptions that libraries can utilize for reporting failures and other events. These exceptions can be imported also directly via robot.api like from robot.api import SkipExecution.
  • parsing module exposing the parsing APIs. This module is new in Robot Framework 4.0. Various parsing related functions and classes were exposed directly via robot.api already in Robot Framework 3.2, but they are effectively deprecated and will be removed in the future.
  • TestSuite class for creating executable test suites programmatically and TestSuiteBuilder class for creating such suites based on existing test data on the file system.
  • SuiteVisitor abstract class for processing testdata before execution. This can be used as a base for implementing a pre-run modifier that is taken into use with --prerunmodifier commandline option.
  • ExecutionResult() factory method for reading execution results from XML output files and ResultVisitor abstract class to ease further processing the results. ResultVisitor can also be used as a base for pre-Rebot modifier that is taken into use with --prerebotmodifier commandline option.
  • ResultWriter class for writing reports, logs, XML outputs, and XUnit files. Can write results based on XML outputs on the file system, as well as based on the result objects returned by the ExecutionResult() or an executed TestSuite.

All of the above names can be imported like:

from robot.api import ApiName

See documentations of the individual APIs for more details.

Tip

APIs related to the command line entry points are exposed directly via the robot root package.

Submodules

robot.api.deco module

robot.api.deco.not_keyword(func)[source]

Decorator to disable exposing functions or methods as keywords.

Examples:

@not_keyword
def not_exposed_as_keyword():
    # ...

def exposed_as_keyword():
    # ...

Alternatively the automatic keyword discovery can be disabled with the library() decorator or by setting the ROBOT_AUTO_KEYWORDS attribute to a false value.

New in Robot Framework 3.2.

robot.api.deco.keyword(name=None, tags=(), types=())[source]

Decorator to set custom name, tags and argument types to keywords.

This decorator creates robot_name, robot_tags and robot_types attributes on the decorated keyword function or method based on the provided arguments. Robot Framework checks them to determine the keyword’s name, tags, and argument types, respectively.

Name must be given as a string, tags as a list of strings, and types either as a dictionary mapping argument names to types or as a list of types mapped to arguments based on position. It is OK to specify types only to some arguments, and setting types to None disables type conversion altogether.

If the automatic keyword discovery has been disabled with the library() decorator or by setting the ROBOT_AUTO_KEYWORDS attribute to a false value, this decorator is needed to mark functions or methods keywords.

Examples:

@keyword
def example():
    # ...

@keyword('Login as user "${user}" with password "${password}"',
         tags=['custom name', 'embedded arguments', 'tags'])
def login(user, password):
    # ...

@keyword(types={'length': int, 'case_insensitive': bool})
def types_as_dict(length, case_insensitive):
    # ...

@keyword(types=[int, bool])
def types_as_list(length, case_insensitive):
    # ...

@keyword(types=None])
def no_conversion(length, case_insensitive=False):
    # ...
robot.api.deco.library(scope=None, version=None, doc_format=None, listener=None, auto_keywords=False)[source]

Class decorator to control keyword discovery and other library settings.

By default disables automatic keyword detection by setting class attribute ROBOT_AUTO_KEYWORDS = False to the decorated library. In that mode only methods decorated explicitly with the keyword() decorator become keywords. If that is not desired, automatic keyword discovery can be enabled by using auto_keywords=True.

Arguments scope, version, doc_format and listener set the library scope, version, documentation format and listener by using class attributes ROBOT_LIBRARY_SCOPE, ROBOT_LIBRARY_VERSION, ROBOT_LIBRARY_DOC_FORMAT and ROBOT_LIBRARY_LISTENER, respectively. These attributes are only set if the related arguments are given and they override possible existing attributes in the decorated class.

Examples:

@library
class KeywordDiscovery:

    @keyword
    def do_something(self):
        # ...

    def not_keyword(self):
        # ...


@library(scope='GLOBAL', version='3.2')
class LibraryConfiguration:
    # ...

The @library decorator is new in Robot Framework 3.2.

robot.api.exceptions module

Exceptions that libraries can use for communicating failures and other events.

These exceptions can be imported also via the top level robot.api package like from robot.api import SkipExecution.

This module and all exceptions are new in Robot Framework 4.0.

exception robot.api.exceptions.Failure(message, html=False)[source]

Bases: exceptions.AssertionError

Report failed validation.

There is no practical difference in using this exception compared to using the standard AssertionError. The main benefits are HTML support and that the name of this exception is consistent with other exceptions in this module.

Parameters:
  • message – Exception message.
  • html – When True, message is considered to be HTML and not escaped.
ROBOT_SUPPRESS_NAME = True
args
message
exception robot.api.exceptions.ContinuableFailure(message, html=False)[source]

Bases: robot.api.exceptions.Failure

Report failed validation but allow continuing execution.

Parameters:
  • message – Exception message.
  • html – When True, message is considered to be HTML and not escaped.
ROBOT_CONTINUE_ON_FAILURE = True
ROBOT_SUPPRESS_NAME = True
args
message
exception robot.api.exceptions.Error(message, html=False)[source]

Bases: exceptions.RuntimeError

Report error in execution.

Failures related to the system not behaving as expected should typically be reported using the Failure exception or the standard AssertionError. This exception can be used, for example, if the keyword is used incorrectly.

There is no practical difference in using this exception compared to using the standard RuntimeError. The main benefits are HTML support and that the name of this exception is consistent with other exceptions in this module.

Parameters:
  • message – Exception message.
  • html – When True, message is considered to be HTML and not escaped.
ROBOT_SUPPRESS_NAME = True
args
message
exception robot.api.exceptions.FatalError(message, html=False)[source]

Bases: robot.api.exceptions.Error

Report error that stops the whole execution.

Parameters:
  • message – Exception message.
  • html – When True, message is considered to be HTML and not escaped.
ROBOT_EXIT_ON_FAILURE = True
ROBOT_SUPPRESS_NAME = False
args
message
exception robot.api.exceptions.SkipExecution(message, html=False)[source]

Bases: exceptions.Exception

Mark the executed test or task skipped.

Parameters:
  • message – Exception message.
  • html – When True, message is considered to be HTML and not escaped.
ROBOT_SKIP_EXECUTION = True
ROBOT_SUPPRESS_NAME = True
args
message

robot.api.logger module

Public logging API for test libraries.

This module provides a public API for writing messages to the log file and the console. Test libraries can use this API like:

logger.info('My message')

instead of logging through the standard output like:

print('*INFO* My message')

In addition to a programmatic interface being cleaner to use, this API has a benefit that the log messages have accurate timestamps.

If the logging methods are used when Robot Framework is not running, the messages are redirected to the standard Python logging module using logger named RobotFramework.

Log levels

It is possible to log messages using levels TRACE, DEBUG, INFO, WARN and ERROR either using the write() function or, more commonly, with the log level specific trace(), debug(), info(), warn(), error() functions.

By default the trace and debug messages are not logged but that can be changed with the --loglevel command line option. Warnings and errors are automatically written also to the console and to the Test Execution Errors section in the log file.

Logging HTML

All methods that are used for writing messages to the log file have an optional html argument. If a message to be logged is supposed to be shown as HTML, this argument should be set to True. Alternatively, write() accepts a pseudo log level HTML.

Example

from robot.api import logger

def my_keyword(arg):
    logger.debug('Got argument %s.' % arg)
    do_something()
    logger.info('<i>This</i> is a boring example.', html=True)
robot.api.logger.write(msg, level='INFO', html=False)[source]

Writes the message to the log file using the given level.

Valid log levels are TRACE, DEBUG, INFO (default), WARN, and ERROR. Additionally it is possible to use HTML pseudo log level that logs the message as HTML using the INFO level.

Instead of using this method, it is generally better to use the level specific methods such as info and debug that have separate html argument to control the message format.

robot.api.logger.trace(msg, html=False)[source]

Writes the message to the log file using the TRACE level.

robot.api.logger.debug(msg, html=False)[source]

Writes the message to the log file using the DEBUG level.

robot.api.logger.info(msg, html=False, also_console=False)[source]

Writes the message to the log file using the INFO level.

If also_console argument is set to True, the message is written both to the log file and to the console.

robot.api.logger.warn(msg, html=False)[source]

Writes the message to the log file using the WARN level.

robot.api.logger.error(msg, html=False)[source]

Writes the message to the log file using the ERROR level.

robot.api.logger.console(msg, newline=True, stream='stdout')[source]

Writes the message to the console.

If the newline argument is True, a newline character is automatically added to the message.

By default the message is written to the standard output stream. Using the standard error stream is possibly by giving the stream argument value 'stderr'.

robot.api.parsing module

Public API for parsing, inspecting and modifying test data.

Exposed API

The publicly exposed parsing entry points are the following:

Note

This module is new in Robot Framework 4.0. In Robot Framework 3.2 functions for getting tokens and model as well as the Token class were exposed directly via the robot.api package, but other parts of the parsing API were not publicly exposed. All code targeting Robot Framework 4.0 or newer should use this module because parsing related functions and classes will be removed from robot.api in the future.

Note

Parsing was totally rewritten in Robot Framework 3.2 and external tools using the parsing APIs need to be updated. Depending on the use case, it may be possible to use the higher level TestSuiteBuilder() instead.

Parsing data to tokens

Data can be parsed to tokens by using get_tokens(), get_resource_tokens() or get_init_tokens() functions depending on whether the data represent a test case (or task) file, a resource file, or a suite initialization file. In practice the difference between these functions is what settings and sections are valid.

Typically the data is easier to inspect and modify by using the higher level model discussed in the next section, but in some cases having just the tokens can be enough. Tokens returned by the aforementioned functions are Token instances and they have the token type, value, and position easily available as their attributes. Tokens also have useful string representation used by the example below:

from robot.api.parsing import get_tokens

path = 'example.robot'

for token in get_tokens(path):
    print(repr(token))

If the example.robot used by the above example would contain

*** Test Cases ***
Example
    Keyword    argument

Second example
    Keyword    xxx

*** Keywords ***
Keyword
    [Arguments]    ${arg}
    Log    ${arg}

then the beginning of the output got when running the earlier code would look like this:

Token(TESTCASE_HEADER, '*** Test Cases ***', 1, 0)
Token(EOL, '\n', 1, 18)
Token(EOS, '', 1, 19)
Token(TESTCASE_NAME, 'Example', 2, 0)
Token(EOL, '\n', 2, 7)
Token(EOS, '', 2, 8)
Token(SEPARATOR, '    ', 3, 0)
Token(KEYWORD, 'Keyword', 3, 4)
Token(SEPARATOR, '    ', 3, 11)
Token(ARGUMENT, 'argument', 3, 15)
Token(EOL, '\n', 3, 23)
Token(EOS, '', 3, 24)
Token(EOL, '\n', 4, 0)
Token(EOS, '', 4, 1)

The output shows the token type, value, line number and column offset. When finding tokens by their type, the constants in the Token class such as Token.TESTCASE_NAME and Token.EOL should be used instead the values of these constants like 'TESTCASE NAME' and 'EOL'. These values have changed slightly in Robot Framework 4.0 and they may change in the future as well.

The EOL tokens denote end of a line and they include the newline character and possible trailing spaces. The EOS tokens denote end of a logical statement. Typically a single line forms a statement, but when the ... syntax is used for continuation, a statement spans multiple lines. In special cases a single line can also contain multiple statements.

Errors caused by unrecognized data such as non-existing section or setting names are handled during the tokenizing phase. Such errors are reported using tokens that have ERROR type and the actual error message in their error attribute. Syntax errors such as empty FOR loops are only handled when building the higher level model discussed below.

See the documentation of get_tokens() for details about different ways how to specify the data to be parsed, how to control should all tokens or only data tokens be returned, and should variables in keyword arguments and elsewhere be tokenized or not.

Parsing data to model

Data can be parsed to a higher level model by using get_model(), get_resource_model(), or get_init_model() functions depending on the type of the parsed file same way as when parsing data to tokens.

The model is represented as an abstract syntax tree (AST) implemented on top of Python’s standard ast.AST class. To see how the model looks like, it is possible to use the ast.dump() function or the third-party astpretty module:

import ast
import astpretty
from robot.api.parsing import get_model

model = get_model('example.robot')
print(ast.dump(model, include_attributes=True))
print('-' * 72)
astpretty.pprint(model)

Running this code with the example.robot file from the previous section would produce so much output that it is not included here. If you are going to work with Robot Framework’s AST, you are recommended to try that on your own.

Model objects

The model is build from nodes that are based ast.AST and further categorized to blocks and statements. Blocks can contain other blocks and statements as child nodes whereas statements only have tokens containing the actual data as Token instances. Both statements and blocks expose their position information via lineno, col_offset, end_lineno and end_col_offset attributes and some nodes have also other special attributes available.

Blocks:

Statements:

Inspecting model

The easiest way to inspect what data a model contains is implementing ModelVisitor and creating visit_NodeName to visit nodes with name NodeName as needed. The following example illustrates how to find what tests a certain test case file contains:

from robot.api.parsing import get_model, ModelVisitor


class TestNamePrinter(ModelVisitor):

    def visit_File(self, node):
        print(f"File '{node.source}' has following tests:")
        # Call `generic_visit` to visit also child nodes.
        self.generic_visit(node)

    def visit_TestCaseName(self, node):
        print(f"- {node.name} (on line {node.lineno})")


model = get_model('example.robot')
printer = TestNamePrinter()
printer.visit(model)

When the above code is run using the earlier example.robot, the output is this:

File 'example.robot' has following tests:
- Example (on line 2)
- Second example (on line 5)

Handling errors in model

All nodes in the model have errors attribute that contains possible errors the node has. These errors include syntax errors such as empty FOR loops or IF without a condition as well as errors caused by unrecognized data such as non-existing section or setting names.

Unrecognized data is handled already during the tokenizing phase. In the model such data is represented as Error nodes and their errors attribute contain error information got from the underlying ERROR tokens. Syntax errors do not create Error nodes, but instead the model has normal nodes such as If with errors in their errors attribute.

A simple way to go through the model and see are there errors is using the ModelVisitor discussed in the previous section:

class ErrorReporter(ModelVisitor):

    # Implement `generic_visit` to visit all nodes.
    def generic_visit(self, node):
        if node.errors:
            print(f'Error on line {node.lineno}:')
            for error in node.errors:
                print(f'- {error}')
        ModelVisitor.generic_visit(self, node)

Modifying data

Existing data the model contains can be modified simply by modifying values of the underlying tokens. If changes need to be saved, that is as easy as calling the save() method of the root model object. When just modifying token values, it is possible to still use ModelVisitor discussed in the above section. The next section discusses adding or removing nodes and then ModelTransformer should be used instead.

Modifications to tokens obviously require finding the tokens to be modified. The first step is finding nodes containing the tokens by implementing needed visit_NodeName methods. Then the exact token or tokens can be found using nodes’ get_token() or get_tokens() methods. If only token values are needed, get_value() or get_values() can be used as a shortcut. First finding nodes and then the right tokens is illustrated by this keyword renaming example:

from robot.api.parsing import get_model, ModelVisitor, Token


class KeywordRenamer(ModelVisitor):

    def __init__(self, old_name, new_name):
        self.old_name = self.normalize(old_name)
        self.new_name = new_name

    def normalize(self, name):
        return name.lower().replace(' ', '').replace('_', '')

    def visit_KeywordName(self, node):
        '''Rename keyword definitions.'''
        if self.normalize(node.name) == self.old_name:
            token = node.get_token(Token.KEYWORD_NAME)
            token.value = self.new_name

    def visit_KeywordCall(self, node):
        '''Rename keyword usages.'''
        if self.normalize(node.keyword) == self.old_name:
            token = node.get_token(Token.KEYWORD)
            token.value = self.new_name


model = get_model('example.robot')
renamer = KeywordRenamer('Keyword', 'New Name')
renamer.visit(model)
model.save()

If you run the above example using the earlier example.robot, you can see that the Keyword keyword has been renamed to New Name. Notice that a real keyword renamer needed to take into account also keywords used with setups, teardowns and templates.

When token values are changed, column offset of the other tokens on same line are likely to be wrong. This does not affect saving the model or other typical usages, but if it is a problem then the caller needs to updated offsets separately.

Adding and removing nodes

Bigger changes to the model are somewhat more complicated than just modifying existing token values. When doing this kind of changes, ModelTransformer should be used instead of ModelVisitor that was discussed in the previous sections.

Removing nodes is relative easy and is accomplished by returning None from visit_NodeName methods. Remember to return the original node, or possibly a replacement node, from all of these methods when you do not want a node to be removed.

Adding nodes requires constructing needed Model objects and adding them to the model. The following example demonstrates both removing and adding nodes. If you run it against the earlier example.robot, you see that the first test gets a new keyword, the second test is removed, and settings section with documentation is added.

from robot.api.parsing import (
    get_model, Documentation, EmptyLine, KeywordCall,
    ModelTransformer, SettingSection, SectionHeader, Token
)


class TestModifier(ModelTransformer):

    def visit_TestCase(self, node):
        # The matched `TestCase` node is a block with `header` and
        # `body` attributes. `header` is a statement with familiar
        # `get_token` and `get_value` methods for getting certain
        # tokens or their value.
        name = node.header.get_value(Token.TESTCASE_NAME)
        # Returning `None` drops the node altogether i.e. removes
        # this test.
        if name == 'Second example':
            return None
        # Construct new keyword call statement from tokens. See `visit_File`
        # below for an example creating statements using `from_params`.
        new_keyword = KeywordCall([
            Token(Token.SEPARATOR, '    '),
            Token(Token.KEYWORD, 'New Keyword'),
            Token(Token.SEPARATOR, '    '),
            Token(Token.ARGUMENT, 'xxx'),
            Token(Token.EOL)
        ])
        # Add the keyword call to test as the second item.
        node.body.insert(1, new_keyword)
        # No need to call `generic_visit` because we are not
        # modifying child nodes. The node itself must to be
        # returned to avoid dropping it.
        return node

    def visit_File(self, node):
        # Create settings section with documentation. Needed header and body
        # statements are created using `from_params` method. This is typically
        # more convenient than creating statements based on tokens like above.
        settings = SettingSection(
            header=SectionHeader.from_params(Token.SETTING_HEADER),
            body=[
                Documentation.from_params('This is a really\npowerful API!'),
                EmptyLine.from_params()
            ]
        )
        # Add settings to the beginning of the file.
        node.sections.insert(0, settings)
        # Call `generic_visit` to visit also child nodes.
        return self.generic_visit(node)


model = get_model('example.robot')
TestModifier().visit(model)
model.save('modified.robot')

Executing model

It is possible to convert a parsed and possibly modified model into an executable TestSuite structure by using its from_model() class method. In this case the get_model() function should be given the curdir argument to get possible ${CURDIR} variable resolved correctly.

from robot.api import TestSuite
from robot.api.parsing import get_model

model = get_model('example.robot', curdir='/home/robot/example')
# modify model as needed
suite = TestSuite.from_model(model)
suite.run()

For more details about executing the created TestSuite object, see the documentation of its run() method. Notice also that if you do not need to modify the parsed model, it is easier to get the executable suite by using the from_file_system() class method.