Support for different runtimes
The Robot Framework not only works on the native python (CPython/pypy
installations ), but also supports Java and .NET based runtimes in the form of Jython and ironpython respectively. While there are some features that are exclusive to native Python-or Jython-based Robot Framework installations, most of the functionality is equivalent on all the runtimes. As people might have different OS and application software a stack setup according to their needs or desires, so they can integrate this tool in their existing runtime without requiring a separate runtime.
Based upon the installer environment used, the Robot Framework will create appropriate startup and post-processing scripts:
Environment |
Startup command |
Post-processing command |
---|---|---|
Python |
|
|
Jython |
|
|
Iron Python |
|
|
In addition to these commands used in starting the execution, the Robot Framework can directly be started through the robot.run
module itself if the standard Robot Framework is installed. This can also be used instead of the standard commands as the commands also call the module internally. The module can be called if the Python command in use is the one that has the Robot Framework installed:
python -m robot.run jython .../run.py ipy -m robot.run
This is handy if the Robot Framework is called by some the Python script. Instead of executing the scripts separately, you can call the framework from inside the same program easily.
The post processing command is useful to recreate test executions in the long run. After the test has been executed, you can save the XML file generated as output without saving any other file. To recreate the report and log files again in future, the rebot
command can be used which takes the XML file as an argument and results in the generation of the log and report files without recalling or running the actual tests again.
Command details
The Pybot
command provides the following major options:
Options |
Description |
---|---|
|
Sets the name of topmost test suite in the test hierarchy—thereby effectively customizes those areas. |
|
Sets the documentation of the top level test suite. |
|
Sets the metadata of the top level test suite. |
|
Sets the given tag to all executed test cases. |
|
Selects the test cases available by performing a pattern match against them. |
|
Selects the specified test suite by its name and also allows for the test reports to have the desired name instead of the name picked up by file/folder name. |
|
Selects a test for execution on the basis of its tag name. |
|
Opposite of include tag. |
|
Selected failed tests of earlier test runs have another goal. |
|
Tests having this tag are considered critical (default for all tests). |
|
Tests having this tag are overridden to be of non-critical type. |
|
Set variables in tests, only scalar variables(${}) are supported. |
|
Specify explicitly the file that contains variables. |
|
Specify the desired directory where resultant files are placed. |
|
The generated XML output file. |
|
The generated HTML log file. |
|
The generated HTML log file. |
|
xUnit compatible result file (not created by default). |
|
Debug file written during the execution(not created by default). |
|
Adds timestamp and provides a custom title to all output files. |
|
Threshold level for logging and logging and test order customization. |
|
Specify the width of monitor output. |
|
Specify whether to use color on console or not. |
|
Specify test success on console for each test that passes. |
|
Additional locations to search test libraries from. |
|
Specify escape characters in console with common representation. |
|
Specify a text file to read more arguments in tests. |
|
Prints detailed help for the command. |
|
Prints the version of the installed Robot Framework. |