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.

Currently exposed APIs are:

• logger module for test libraries’ logging purposes.
• deco module with decorators test libraries can utilize.
• TestCaseFile, TestDataDirectory, and ResourceFile classes for parsing test data files and directories. In addition, a convenience factory method TestData() creates either TestCaseFile or TestDataDirectory objects based on the input.
• 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.keyword(name=None, tags=(), types=())

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 method or function 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 (or tuple) 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.

Examples:

@keyword(name='Login Via User Panel')
def login(username, password):
    # ...

@keyword(name='Logout Via User Panel', tags=['example', 'tags'])
def logout():
    # ...

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

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

@keyword(types=None])
def no_conversion(length, case_insensitive=False):
    # ...

If name is not given, the actual name of the keyword will not be affected, but the robot_name attribute will still be created. This can be useful for marking methods as keywords in a dynamic library. In this usage it is possible to also omit parenthesis when using the decorator:

@keyword
def func():
    # ...

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. The support for the error level and function is new in RF 2.9.

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)

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

Valid log levels are TRACE, DEBUG, INFO (default since RF 2.9.1), WARN, and ERROR (new in RF 2.9). 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)

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

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

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

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

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)

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

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

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

New in Robot Framework 2.9.

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

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'.