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 viarobot.api
likefrom robot.api import SkipExecution
.interfaces
module containing optional base classes that can be used when creating libraries and other extensions. New in Robot Framework 6.1.parsing
module exposing the parsing APIs. This module is new in Robot Framework 4.0. Various parsing related functions and classes were exposed directly viarobot.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 andTestSuiteBuilder
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 andResultVisitor
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 theExecutionResult()
or an executedTestSuite
.TypeInfo
class for parsing type hints and converting values based on them. New in Robot Framework 7.0.Languages
andLanguage
classes for external tools that need to work with different translations. The latter is also the base class to use with custom translations.
All of the above classes can be imported like:
from robot.api import ClassName
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: F) F [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 theROBOT_AUTO_KEYWORDS
attribute to a false value.New in Robot Framework 3.2.
- robot.api.deco.keyword(func: K, /) K [source]
- robot.api.deco.keyword(name: str | None = None, tags: Sequence[str] = (), types: TypeHints | None = ()) Callable[[K], K]
Decorator to set custom name, tags and argument types to keywords.
This decorator creates
robot_name
,robot_tags
androbot_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
toNone
disables type conversion altogether.If the automatic keyword discovery has been disabled with the
library()
decorator or by setting theROBOT_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(cls: L, /) L [source]
- robot.api.deco.library(scope: str | None = None, version: str | None = None, converters: dict[type, Callable[[Any], Any] | Callable[[Any, Any], Any]] | None = None, doc_format: str | None = None, listener: Any | None = None, auto_keywords: bool = False) Callable[[L], L]
Class decorator to control keyword discovery and other library settings.
Disables automatic keyword detection by setting class attribute
ROBOT_AUTO_KEYWORDS = False
to the decorated library by default. In that mode only methods decorated explicitly with thekeyword()
decorator become keywords. If that is not desired, automatic keyword discovery can be enabled by usingauto_keywords=True
.Arguments
scope
,version
,converters
,doc_format
andlistener
set library’s scope, version, converters, documentation format and listener by using class attributesROBOT_LIBRARY_SCOPE
,ROBOT_LIBRARY_VERSION
,ROBOT_LIBRARY_CONVERTERS
,ROBOT_LIBRARY_DOC_FORMAT
andROBOT_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. Theconverters
argument is new in Robot Framework 5.0.
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: str, html: bool = False)[source]
Bases:
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
- exception robot.api.exceptions.ContinuableFailure(message: str, html: bool = False)[source]
Bases:
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
- exception robot.api.exceptions.Error(message: str, html: bool = False)[source]
Bases:
RuntimeError
Report error in execution.
Failures related to the system not behaving as expected should typically be reported using the
Failure
exception or the standardAssertionError
. 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
- exception robot.api.exceptions.FatalError(message: str, html: bool = False)[source]
Bases:
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
- exception robot.api.exceptions.SkipExecution(message: str, html: bool = False)[source]
Bases:
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
robot.api.interfaces module
Optional base classes for libraries and other extensions.
Module contents:
DynamicLibrary
for libraries using the dynamic library API.HybridLibrary
for libraries using the hybrid library API.Parser
for custom parsers. AlsoTestDefaults
used inParser
type hints can be imported via this module if needed.Type definitions used by the aforementioned classes.
Main benefit of using these base classes is that editors can provide automatic completion, documentation and type information. Their usage is not required. Notice also that libraries typically use the static API and do not need any base class.
Note
These classes are not exposed via the top level robot.api
package and need to imported via robot.api.interfaces
.
This module is new in Robot Framework 6.1.
- class robot.api.interfaces.DynamicLibrary[source]
Bases:
ABC
Optional base class for libraries using the dynamic library API.
The dynamic library API makes it possible to dynamically specify what keywords a library implements and run them by using
get_keyword_names()
andrun_keyword()
methods, respectively. In addition to that it has various optional methods for returning more information about the implemented keywords to Robot Framework.- abstract get_keyword_names() Sequence[str] [source]
Return names of the keywords this library implements.
- Returns:
Keyword names as a list of strings.
name
passed to other methods is always in the same format as returned by this method.
- abstract run_keyword(name: str, args: Sequence[Any], named: Mapping[str, Any]) Any [source]
Execute the specified keyword using the given arguments.
- Parameters:
name – Keyword name as a string.
args – Positional arguments as a list.
named – Named arguments as a dictionary.
- Raises:
Reporting FAIL or SKIP status.
- Returns:
Keyword’s return value.
Reporting status, logging, returning values, etc. is handled the same way as with the normal static library API.
- get_keyword_documentation(name: str) str | None [source]
Optional method to return keyword documentation.
The first logical line of keyword documentation is shown in the execution log under the executed keyword. The whole documentation is shown in documentation generated by Libdoc.
- Parameters:
name – Keyword name as a string.
- Returns:
Documentation as a string oras
None
if there is no documentation.
This method is also used to get the overall library documentation as well as documentation related to importing the library. They are got by calling this method with special names
__intro__
and__init__
, respectively.
- get_keyword_arguments(name: str) Sequence[str | tuple[str] | tuple[str, Any]] | None [source]
Optional method to return keyword’s argument specification.
Returned information is used during execution for argument validation. In addition to that, arguments are shown in documentation generated by Libdoc.
- Parameters:
name – Keyword name as a string.
- Returns:
Argument specification using format explained below.
Argument specification defines what arguments the keyword accepts. Returning
None
means that the keywords accepts any arguments. Accepted arguments are returned as a list using these rules:Normal arguments are specified as a list of strings like
['arg1', 'arg2']
. An empty list denotes that the keyword accepts no arguments.Varargs must have a
*
prefix like['*numbers']
. There can be only one varargs, and it must follow normal arguments.Arguments after varargs like
['*items', 'arg']
are considered named-only arguments.If keyword does not accept varargs, a lone
*
can be used a separator between normal and named-only arguments like['normal', '*', 'named']
.Kwargs must have a
**
prefix like['**config']
. There can be only one kwargs, and it must be last.
Both normal arguments and named-only arguments can have default values:
Default values can be embedded to argument names so that they are separated with the equal sign like
name=default
. In this case the default value type is always a string.Alternatively arguments and their default values can be represented as two-tuples like
('name', 'default')
. This allows non-string default values and automatic argument conversion based on them.Arguments without default values can also be specified as tuples containing just the name like
('name',)
.With normal arguments, arguments with default values must follow arguments without them. There is no such restriction with named-only arguments.
- get_keyword_types(name: str) Mapping[str, type | str | UnionType | tuple[type | str | UnionType | tuple[TypeHint, ...], ...]] | Sequence[type | str | UnionType | tuple[type | str | UnionType | tuple[TypeHint, ...], ...] | None] | None [source]
Optional method to return keyword’s type specification.
Type information is used for automatic argument conversion during execution. It is also shown in documentation generated by Libdoc.
- Parameters:
name – Keyword name as a string.
- Returns:
Type specification as a dictionary, as a list, or as
None
if type information is not known.
Type information can be mapped to arguments returned by
get_keyword_names()
either by names using a dictionary or by position using a list. For example, if a keyword has argument specification['arg', 'second']
, it would be possible to return types both like{'arg': str, 'second': int}
and[str, int]
.Regardless of the approach that is used, it is not necessarily to specify types for all arguments. When using a dictionary, some arguments can be omitted altogether. When using a list, it is possible to use
None
to mark that a certain argument does not have type information and arguments at the end can be omitted altogether.If is possible to specify that an argument has multiple possible types by using unions like
{'arg': Union[int, float]}
or tuples like{'arg': (int, float)}
.In addition to specifying types using classes, it is also possible to use names or aliases like
{'a': 'int', 'b': 'boolean'}
. For an up-to-date list of supported types, names and aliases see the User Guide.
- get_keyword_tags(name: str) Sequence[str] | None [source]
Optional method to return keyword’s tags.
Tags are shown in the execution log and in documentation generated by Libdoc. Tags can also be used with various command line options.
- Parameters:
name – Keyword name as a string.
- Returns:
Tags as a list of strings or
None
if there are no tags.
- get_keyword_source(name: str) str | None [source]
Optional method to return keyword’s source path and line number.
Source information is used by IDEs to provide navigation from keyword usage to implementation.
- Parameters:
name – Keyword name as a string.
- Returns:
Source as a string in format
path:lineno
orNone
if source is not known.
The general format to return the source is
path:lineno
like/example/Lib.py:42
. If the line number is not known, it is possible to return only the path. If the keyword is in the same file as the main library class, the path can be omitted and only the line number returned like:42
.The source information of the library itself is got automatically from the imported library class. The library source path is used with all keywords that do not return their own path.
- class robot.api.interfaces.HybridLibrary[source]
Bases:
ABC
Optional base class for libraries using the hybrid library API.
Hybrid library API makes it easy to specify what keywords a library implements by using the
get_keyword_names()
method. After getting keyword names, Robot Framework usesgetattr
to get the actual keyword methods exactly like it does when using the normal static library API. Keyword name, arguments, documentation, tags, and so on are got directly from the keyword method.It is possible to implement keywords also outside the main library class. In such cases the library needs to have a
__getattr__
method that returns desired keyword methods.
- class robot.api.interfaces.StartSuiteAttributes[source]
Bases:
TypedDict
Attributes passed to listener v2
start_suite
method.See the User Guide for more information.
- id: str
- longname: str
- doc: str
- metadata: dict[str, str]
- source: str
- suites: list[str]
- tests: list[str]
- totaltests: int
- starttime: str
- class robot.api.interfaces.EndSuiteAttributes[source]
Bases:
StartSuiteAttributes
Attributes passed to listener v2
end_suite
method.See the User Guide for more information.
- endtime: str
- elapsedtime: int
- status: str
- statistics: str
- message: str
- id: str
- longname: str
- doc: str
- metadata: dict[str, str]
- source: str
- suites: list[str]
- tests: list[str]
- totaltests: int
- starttime: str
- class robot.api.interfaces.StartTestAttributes[source]
Bases:
TypedDict
Attributes passed to listener v2
start_test
method.See the User Guide for more information.
- id: str
- longname: str
- originalname: str
- doc: str
- tags: list[str]
- template: str
- source: str
- lineno: int
- starttime: str
- class robot.api.interfaces.EndTestAttributes[source]
Bases:
StartTestAttributes
Attributes passed to listener v2
end_test
method.See the User Guide for more information.
- endtime: str
- elapedtime: int
- status: str
- message: str
- id: str
- longname: str
- originalname: str
- doc: str
- tags: list[str]
- template: str
- source: str
- lineno: int
- starttime: str
- class robot.api.interfaces.OptionalKeywordAttributes[source]
Bases:
TypedDict
Extra attributes passed to listener v2
start/end_keyword
methods.These attributes are included with control structures. For example, with IF structures attributes include
condition
.- variables: list[str] | dict[str, str]
- flavor: str
- condition: str
- limit: str
- patterns: list[str]
- pattern_type: str
- variable: str
- class robot.api.interfaces.StartKeywordAttributes[source]
Bases:
OptionalKeywordAttributes
Attributes passed to listener v2
start_keyword
method.See the User Guide for more information.
- type: str
- kwname: str
- libname: str
- doc: str
- args: list[str]
- assign: list[str]
- tags: list[str]
- source: str
- lineno: int
- status: str
- starttime: str
- variables: list[str] | dict[str, str]
- flavor: str
- condition: str
- limit: str
- patterns: list[str]
- pattern_type: str
- variable: str
- class robot.api.interfaces.EndKeywordAttributes[source]
Bases:
StartKeywordAttributes
Attributes passed to listener v2
end_keyword
method.See the User Guide for more information.
- endtime: str
- elapsedtime: int
- variables: list[str] | dict[str, str]
- flavor: str
- condition: str
- limit: str
- patterns: list[str]
- pattern_type: str
- variable: str
- type: str
- kwname: str
- libname: str
- doc: str
- args: list[str]
- assign: list[str]
- tags: list[str]
- source: str
- lineno: int
- status: str
- starttime: str
- class robot.api.interfaces.MessageAttributes[source]
Bases:
TypedDict
Attributes passed to listener v2
log_message
andmessages
methods.See the User Guide for more information.
- message: str
- level: str
- timestamp: str
- html: str
- class robot.api.interfaces.LibraryAttributes[source]
Bases:
TypedDict
Attributes passed to listener v2
library_import
method.See the User Guide for more information.
- args: list[str]
- originalname: str
- source: str
- importer: str | None
- class robot.api.interfaces.ResourceAttributes[source]
Bases:
TypedDict
Attributes passed to listener v2
resource_import
method.See the User Guide for more information.
- source: str
- importer: str | None
- class robot.api.interfaces.VariablesAttributes[source]
Bases:
TypedDict
Attributes passed to listener v2
variables_import
method.See the User Guide for more information.
- args: list[str]
- source: str
- importer: str | None
- class robot.api.interfaces.ListenerV2[source]
Bases:
object
Optional base class for listeners using the listener API version 2.
- ROBOT_LISTENER_API_VERSION = 2
- start_suite(name: str, attributes: StartSuiteAttributes)[source]
Called when a suite starts.
- end_suite(name: str, attributes: EndSuiteAttributes)[source]
Called when a suite end.
- start_test(name: str, attributes: StartTestAttributes)[source]
Called when a test or task starts.
- end_test(name: str, attributes: EndTestAttributes)[source]
Called when a test or task ends.
- start_keyword(name: str, attributes: StartKeywordAttributes)[source]
Called when a keyword or a control structure like IF starts.
The type of the started item is in
attributes['type']
. Control structures can contain extra attributes that are only relevant to them.
- end_keyword(name: str, attributes: EndKeywordAttributes)[source]
Called when a keyword or a control structure like IF ends.
The type of the started item is in
attributes['type']
. Control structures can contain extra attributes that are only relevant to them.
- log_message(message: MessageAttributes)[source]
Called when a normal log message are emitted.
The messages are typically logged by keywords, but also the framework itself logs some messages. These messages end up to output.xml and log.html.
- message(message: MessageAttributes)[source]
Called when framework’s internal messages are emitted.
Only logged by the framework itself. These messages end up to the syslog if it is enabled.
- library_import(name: str, attributes: LibraryAttributes)[source]
Called after a library has been imported.
- resource_import(name: str, attributes: ResourceAttributes)[source]
Called after a resource file has been imported.
- variables_import(name: str, attributes: VariablesAttributes)[source]
Called after a variable file has been imported.
- class robot.api.interfaces.ListenerV3[source]
Bases:
object
Optional base class for listeners using the listener API version 3.
- ROBOT_LISTENER_API_VERSION = 3
- start_keyword(data: Keyword, result: Keyword)[source]
Called when a keyword starts by default.
This method is called, by default, with user keywords, library keywords and when a keyword call is invalid. It is not called, however, if a more specific
start_user_keyword()
,start_library_keyword()
orstart_invalid_keyword()
method is implemented.The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_keyword(data: Keyword, result: Keyword)[source]
Called when a keyword ends by default.
This method is called, by default, with user keywords, library keywords and when a keyword call is invalid. It is not called, however, if a more specific
end_user_keyword()
,end_library_keyword()
orend_invalid_keyword()
method is implemented.The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_user_keyword(data: Keyword, implementation: UserKeyword, result: Keyword)[source]
Called when a user keyword starts.
The default implementation calls
start_keyword()
.New in Robot Framework 7.0.
- end_user_keyword(data: Keyword, implementation: UserKeyword, result: Keyword)[source]
Called when a user keyword ends.
The default implementation calls
end_keyword()
.New in Robot Framework 7.0.
- start_library_keyword(data: Keyword, implementation: LibraryKeyword, result: Keyword)[source]
Called when a library keyword starts.
The default implementation calls
start_keyword()
.New in Robot Framework 7.0.
- end_library_keyword(data: Keyword, implementation: LibraryKeyword, result: Keyword)[source]
Called when a library keyword ends.
The default implementation calls
start_keyword()
.New in Robot Framework 7.0.
- start_invalid_keyword(data: Keyword, implementation: KeywordImplementation, result: Keyword)[source]
Called when an invalid keyword call starts.
Keyword may not have been found, there could have been multiple matches, or the keyword call itself could have been invalid.
The default implementation calls
start_keyword()
.New in Robot Framework 7.0.
- end_invalid_keyword(data: Keyword, implementation: KeywordImplementation, result: Keyword)[source]
Called when an invalid keyword call ends.
Keyword may not have been found, there could have been multiple matches, or the keyword call itself could have been invalid.
The default implementation calls
end_keyword()
.New in Robot Framework 7.0.
- start_for(data: For, result: For)[source]
Called when a FOR loop starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_for(data: For, result: For)[source]
Called when a FOR loop ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_for_iteration(data: ForIteration, result: ForIteration)[source]
Called when a FOR loop iteration starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_for_iteration(data: ForIteration, result: ForIteration)[source]
Called when a FOR loop iteration ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_while(data: While, result: While)[source]
Called when a WHILE loop starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_while(data: While, result: While)[source]
Called when a WHILE loop ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_while_iteration(data: WhileIteration, result: WhileIteration)[source]
Called when a WHILE loop iteration starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_while_iteration(data: WhileIteration, result: WhileIteration)[source]
Called when a WHILE loop iteration ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_if(data: If, result: If)[source]
Called when an IF/ELSE structure starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_if(data: If, result: If)[source]
Called when an IF/ELSE structure ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_if_branch(data: IfBranch, result: IfBranch)[source]
Called when an individual IF/ELSE branch starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_if_branch(data: IfBranch, result: IfBranch)[source]
Called when an individual IF/ELSE branch ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_try(data: Try, result: Try)[source]
Called when a TRY/EXCEPT structure starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_try(data: Try, result: Try)[source]
Called when a TRY/EXCEPT structure ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_try_branch(data: TryBranch, result: TryBranch)[source]
Called when an individual TRY/EXCEPT branch starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_try_branch(data: TryBranch, result: TryBranch)[source]
Called when an individual TRY/EXCEPT branch ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_var(data: Var, result: Var)[source]
Called when VAR starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_var(data: Var, result: Var)[source]
Called when VAR ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_break(data: Break, result: Break)[source]
Called when BREAK starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_break(data: Break, result: Break)[source]
Called when BREAK ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_continue(data: Continue, result: Continue)[source]
Called when CONTINUE starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_continue(data: Continue, result: Continue)[source]
Called when CONTINUE ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_return(data: Return, result: Return)[source]
Called when RETURN starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_return(data: Return, result: Return)[source]
Called when RETURN ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_error(data: Error, result: Error)[source]
Called when encountered invalid syntax starts.
The default implementation calls
start_body_item()
.New in Robot Framework 7.0.
- end_error(data: Error, result: Error)[source]
Called when encountered invalid syntax ends.
The default implementation calls
end_body_item()
.New in Robot Framework 7.0.
- start_body_item(data, result)[source]
Called by default when a keyword or a control structure starts.
New in Robot Framework 7.0.
- end_body_item(data, result)[source]
Called by default when a keyword or a control structure ends.
New in Robot Framework 7.0.
- log_message(message: Message)[source]
Called when a normal log message are emitted.
The messages are typically logged by keywords, but also the framework itself logs some messages. These messages end up to output.xml and log.html.
- message(message: Message)[source]
Called when framework’s internal messages are emitted.
Only logged by the framework itself. These messages end up to the syslog if it is enabled.
- library_import(library: TestLibrary, importer: Import)[source]
Called after a library has been imported.
library
represents the imported library. It can be inspected and also modified.importer
contains information about the location where the library was imported.New in Robot Framework 7.1.
- resource_import(resource: ResourceFile, importer: Import)[source]
Called after a resource file has been imported.
resource
represents the imported resource file. It can be inspected and also modified.importer
contains information about the location where the resource was imported.New in Robot Framework 7.1.
- variables_import(attrs: dict, importer: Import)[source]
Called after a variable file has been imported.
attrs
contains information about the imported variable file. It can be inspected, but modifications to it have no effect. importer` contains information about the location where the variable file was imported.New in Robot Framework 7.1. This method will be changed in the future so that the
attrs
dictionary is replaced with an object representing the imported variable file.
- class robot.api.interfaces.Parser[source]
Bases:
ABC
Optional base class for custom parsers.
Parsers do not need to explicitly extend this class and in simple cases it is possible to implement them as modules. Regardless how a parser is implemented, it must have
extension
attribute andparse()
method. Theparse_init()
method is optional and only needed if a parser supports parsing suite initialization files.The mandatory
extension
attribute specifies what file extension or extensions a parser supports. It can be set either as a class or instance attribute, and it can be either a string or a sequence of strings. The attribute can also be namedEXTENSION
, which typically works better when a parser is implemented as a module.Example:
from pathlib import Path from robot.api import TestSuite from robot.api.interfaces import Parser, TestDefaults class ExampleParser(Parser): extension = '.example' def parse(self, source: Path, defaults: TestDefaults) -> TestSuite: suite = TestSuite(TestSuite.name_from_source(source), source=source) # parse the source file and add tests to the created suite return suite
The support for custom parsers is new in Robot Framework 6.1.
- extension: str | Sequence[str]
- abstract parse(source: Path, defaults: TestDefaults) TestSuite [source]
Mandatory method for parsing suite files.
- Parameters:
source – Path to the file to parse.
defaults – Default values set for test in init files.
The
defaults
argument is optional. It is possible to implement this method also so that it accepts onlysource
.
- parse_init(source: Path, defaults: TestDefaults) TestSuite [source]
Optional method for parsing suite initialization files.
- Parameters:
source – Path to the file to parse.
defaults – Default values to used with tests in child suites.
The
defaults
argument is optional. It is possible to implement this method also so that it accepts onlysource
.If this method is not implemented, possible initialization files cause an error.
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 trace and debug messages are not logged by default, 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(f'Got argument {arg}.')
do_something()
logger.info('<i>This</i> is a boring example.', html=True)
- robot.api.logger.write(msg: str, level: Literal['TRACE', 'DEBUG', 'INFO', 'CONSOLE', 'HTML', 'WARN', 'ERROR'] = 'INFO', html: bool = False)[source]
Writes the message to the log file using the given level.
Valid log levels are
TRACE
,DEBUG
,INFO
(default),WARN
, andERROR
. In addition to that, there are pseudo log levelsHTML
andCONSOLE
for logging messages as HTML and for logging messages both to the log file and to the console, respectively. With both of these pseudo levels the level in the log file will beINFO
. TheCONSOLE
level is new in Robot Framework 6.1.Instead of using this method, it is generally better to use the level specific methods such as
info
anddebug
that have separatehtml
argument to control the message format.
- robot.api.logger.trace(msg: str, html: bool = False)[source]
Writes the message to the log file using the
TRACE
level.
- robot.api.logger.debug(msg: str, html: bool = False)[source]
Writes the message to the log file using the
DEBUG
level.
- robot.api.logger.info(msg: str, html: bool = False, also_console: bool = False)[source]
Writes the message to the log file using the
INFO
level.If
also_console
argument is set toTrue
, the message is written both to the log file and to the console.
- robot.api.logger.warn(msg: str, html: bool = False)[source]
Writes the message to the log file using the
WARN
level.
- robot.api.logger.error(msg: str, html: bool = False)[source]
Writes the message to the log file using the
ERROR
level.
- robot.api.logger.console(msg: str, newline: bool = True, stream: Literal['stdout', 'stderr'] = 'stdout')[source]
Writes the message to the console.
If the
newline
argument isTrue
, a newline character is automatically added to the message.The message is written to the standard output stream by default. 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:
get_tokens()
,get_resource_tokens()
, andget_init_tokens()
functions for parsing data to tokens.Token
class that contains all token types as class attributes.get_model()
,get_resource_model()
, andget_init_model()
functions for parsing data to model represented as an abstract syntax tree (AST).Model objects used by the AST model.
ModelVisitor
to ease inspecting model and modifying data.
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:
File
(the root of the model)
Statements:
ForceTags
Return
(deprecated, will meanReturnStatement
in RF 8.0)ReturnSetting
(alias forReturn
, new in RF 6.1)Var
(new in RF 7.0)Config
(new in RF 6.0)
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 the 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 the 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.