Robot Framework Rpa NEW! Download
Isabella Rodriguez
Robot Framework is a Python-based, extensible keyword-driven automationframework for acceptance testing, acceptance test driven development (ATDD),behavior driven development (BDD) and robotic process automation (RPA). Itcan be used in distributed, heterogeneous environments, where automationrequires using different technologies and interfaces.
The framework has a rich ecosystem around it consisting of various genericlibraries and tools that are developed as separate projects. For moreinformation about Robot Framework and the ecosystem, see
The test data is in simple, easy-to-edit tabular format. WhenRobot Framework is started, it processes the data, executes testcases and generates logs and reports. The core framework does notknow anything about the target under test, and the interaction with itis handled by libraries. Libraries can either use applicationinterfaces directly or use lower level test tools as drivers.
Robot Framework is open source software provided under the Apache License2.0. Robot Framework documentation such as this User Guide use theCreative Commons Attribution 3.0 Unported license. Most libraries and toolsin the larger ecosystem around the framework are also open source, but theymay use different licenses.
The PATH environment variable lists directories where commands executed ina system are searched from. To make using Python, pip and Robot Framework easierfrom the command line, it is recommended to add the Python installation directoryas well as the directory where commands like pip and robot are installedinto PATH.
If you have installed Robot Framework under multiple Python versions,running robot will execute the one first in PATH. To select explicitly,you can run python -m robot and substitute python with the right Pythonversion.
Suite files typically use the .robot extension, but what files areparsed can be configured. Resource files can use the .robotextension as well, but using the dedicated .resource extension isrecommended and may be mandated in the future. Files containing non-ASCIIcharacters must be saved using the UTF-8 encoding.
Robot Framework supports also reStructuredText files so that normalRobot Framework data is embedded into code blocks. Only files withthe .robot.rst extension are parsed by default. If you wouldrather use just .rst or .rest extension, that needs to beconfigured separately.
Robot Framework supports reStructuredText files using .robot.rst,.rst and .rest extensions. To avoid parsing unrelatedreStructuredText files, only files with the .robot.rst extensionare parsed by default when executing a directory. Parsing files withother extensions can be enabled by using either --parseincludeor --extension option.
When executing tests or tasks using the robot command, JSON files withthe custom .rbt extension are parsed automatically. This includesrunning individual JSON files like robot tests.rbt and running directoriescontaining .rbt files. If you would rather use the standard.json extension, you need to configure which files are parsed.
If a language you would need is not available as a built-in language, or youwant to create a totally custom language for some specific need, you can easilycreate a custom language file. Language files are Python files that containone or more language definitions that are all loaded when the language fileis taken into use. Language definitions are created by extending therobot.api.Language base class and overriding class attributes as needed:
Users are generally free to use whatever tags that work in their context.There are, however, certain tags that have a predefined meaning for RobotFramework itself, and using them for other purposes can have unexpectedresults. All special tags Robot Framework has and will have in the futurehave the robot: prefix. To avoid problems, users should thus not use anytag with this prefixes unless actually activating the special functionality.The current reserved tags are listed below, but more such tags are likelyto be added in the future.
Robot Framework has similar test setup and teardown functionality as manyother test automation frameworks. In short, a test setup is somethingthat is executed before a test case, and a test teardown is executedafter a test case. In Robot Framework setups and teardowns are justnormal keywords with possible arguments.
In addition to test automation, Robot Framework can be used for otherautomation purposes, including robotic process automation (RPA).It has always been possible, but Robot Framework 3.1 added officialsupport for automating tasks, not only tests. For most parts creatingtasks works the same way as creating tests and the only real differenceis in terminology. Tasks can also be organized into suites exactly liketest cases.
A test suite created from a directory can have similar settings as a suitecreated from a test case file. Because a directory alone cannot have thatkind of information, it must be placed into a special test suite initializationfile. An initialization file name must always be of the format__init__.ext, where the extension must be one of the supportedfile formats (typically __init__.robot).The name format is borrowed from Python, where files named in this mannerdenote that a directory is a module.
The test suite name is constructed from the file or directory name by default.The name is created so that the extension is ignored, possible underscores arereplaced with spaces, and names fully in lower case are title cased. Forexample, some_tests.robot becomes Some Tests andMy_test_directory becomes My test directory.
The file or directory name can contain a prefix to control the executionorder of the suites. The prefix is separated from the base name by twounderscores and, when constructing the actual test suite name, boththe prefix and underscores are removed. For example files01__some_tests.robot and 02__more_tests.robot create testsuites Some Tests and More Tests, respectively, andthe former is executed before the latter.
In addition to the normal standard libraries listed above, there isalso Remote library that is totally different than the other standardlibraries. It does not have any keywords of its own but it works as aproxy between Robot Framework and actual test library implementations.These libraries can be running on other machines than the coreframework and can even be implemented using languages not supported byRobot Framework natively.
Any test library that is not one of the standard libraries is, bydefinition, an external library. The Robot Framework open source communityhas implemented several generic libraries, such as SeleniumLibrary andSwingLibrary, which are not packaged with the core framework. A list ofpublicly available libraries can be found from
When a variable is used as a scalar like $EXAMPLE, its value is beused as-is. If a variable value is a list or list-like, it is also possibleto use it as a list variable like @EXAMPLE. In this case the list is expandedand individual items are passed in as separate arguments. This is easiest to explainwith an example. Assuming that a variable @USER has value ['robot', 'secret'],the following two test cases are equivalent:
As discussed above, a variable containing a list can be used as a listvariable to pass list items to a keyword as individual arguments.Similarly a variable containing a Python dictionary or a dictionary-likeobject can be used as a dictionary variable like &EXAMPLE. In practicethis means that the dictionary is expanded and individual items are passed asnamed arguments to the keyword. Assuming that a variable &USER hasvalue 'name': 'robot', 'password': 'secret', the following two test casesare equivalent.
Similarly as with test case tags, user keyword tags with the robot:prefix are reserved for special features by Robot Frameworkitself. Users should thus not use any tag with these prefixes unless actuallyactivating the special functionality. Starting from Robot Framework 6.1,flattening keyword during execution time can be taken into use usingreserved tag robot:flatten.
The syntax is such that first the [Arguments] setting isgiven and then argument names are defined in the subsequentcells. Each argument is in its own cell, using the same syntax as withvariables. The keyword must be used with as many arguments as thereare argument names in its signature. The actual argument names do notmatter to the framework, but from users' perspective they shouldbe as descriptive as possible. It is recommendedto use lower-case letters in variable names, either as$my_arg, $my arg or $myArg.
Using the robot:private tag does not outright prevent using the keywordoutside the file where it is created, but such usages will cause a warning.If there is both a public and a private keyword with the same name,the public one will be used but also this situation causes a warning.
Resource files are imported using the Resource setting in theSettings section so that the path to the resource file is given as an argumentto the setting. The recommended extension for resource files is .resource.For backwards compatibility reasons also .robot, .txt and.tsv work, but using .resource may be mandated in the future.
Alternatively variable files can be implemented as classesthat the framework will instantiate. Also in this case it is possible to createvariables as attributes or get them dynamically from the get_variablesmethod. Variable files can also be created as YAML and JSON.
The framework will create an instance of the class using no arguments andvariables will be gotten from the instance. Similarly as with modules,variables can be defined as attributes directlyin the instance or gotten from a special get_variables method.
Execution is normally started using the robot command created as part ofinstallation. Alternatively it is possible to execute the installed robotmodule using the selected Python interpreter. This is especially convenientif Robot Framework has been installed under multiple Python versions.Finally, if you know where the installed robot directory exists, it canbe executed using Python as well.
df19127ead