Robot Framework includes a set of pre-defined variables that are available for use in scripts. These variables, also known as built-in variables, have been established by the creators of the Robot Framework to provide a standard set of values and information for use in scripts. These built-in variables can be leveraged to access various system and environment details, such as the current test case status, log file information, and more. By using these built-in variables, developers can streamline their scripting and reduce the amount of custom code they need to write.
1 . Operating System Variables
Operating system variables refer to environment variables that are defined by the operating system and can be used to store information or data that can be used by the system or various applications. This information may include paths to the system or user-defined directories, environment settings, or other data required for applications to run properly. Operating system variables can be accessed and manipulated using various scripting languages, including the command line, and are commonly used to configure system settings or to pass information to applications. These variables are essential for ensuring the proper functioning of the operating system and its applications.
| Built-In Variables | Explanation |
| ${CURDIR} | The absolute path is a complete reference to a location of a file or directory in a computer file system. In the context of testing, an absolute path can be used to specify the exact location of a test data file. This path includes the full directory hierarchy, starting from the root directory, and includes the file name itself. It is important to note that absolute paths are case-sensitive, meaning that the case of each letter in the path must match exactly in order for the file to be located and accessed correctly. This means that if a path is written in uppercase letters and the file system is case-insensitive, the file may still be inaccessible. The use of absolute paths helps to eliminate confusion and ensure that tests are executed with the correct data. |
| ${TEMPDIR} | An absolute path to the temporary system directory refers to the full path to the location where temporary files or directories can be stored in the operating system. This location is typically used by applications to store temporary files that are required during the execution of a process but are not needed once the process is completed. The absolute path to the temporary system directory can vary depending on the operating system being used. On UNIX-like systems, this path is typically /tmp, while on Windows, it is often c:\Documents and Settings<user>\Local Settings\Temp. These paths are essential for many applications to function correctly, and they are used by the operating system to store files that are temporarily required but should not persist on the system. By using the absolute path, applications can access the correct location for storing temporary files, even if the user has changed the default temporary directory. |
| ${EXECDIR} | The absolute path to the directory where test execution was started refers to the full path to the location where the tests were initiated from the command line or other execution method. This path is essential for many applications to function correctly, as it allows them to access files, resources, and configurations that are required for the tests to run successfully. This path is case-sensitive and provides a clear reference to the location of the tests, which can be used by the test framework or other components of the system to access required files and resources. By using the absolute path, the test framework can ensure that it has access to the correct location for all the required resources, even if the user has changed the default location for the test files. This absolute path is an important piece of information that is used by the test framework to execute the tests correctly and provide reliable results. |
| ${/} | The system directory path separator refers to the character used to separate the different components of a file path in an operating system. This separator is necessary to distinguish between the different parts of a file path, such as the directories, subdirectories, and the file name itself. In UNIX-like systems, the path separator is a forward slash “/”, while in Windows, it is a backslash “\”. Understanding the system directory path separator is important for software developers who need to access files and directories on different operating systems, as it helps ensure that their code is compatible with both Windows and UNIX-like systems. Additionally, it is essential to know the system directory path separator to correctly specify the location of files and resources in the system and to ensure that the software can access them correctly. |
| ${:} | The system path element separator. : in UNIX-like systems and ; in Windows.The system path element separator refers to the character used to separate different paths in the system environment variables. The path element separator is used to define the locations of resources, such as executable files and libraries, that the operating system should look in when trying to find a specific command or resource. In UNIX-like systems, the path element separator is a colon “:”, while in Windows, it is a semicolon “;”. Knowing the system path element separator is important for software developers as they need to ensure that their code is compatible with different operating systems and can locate the necessary resources on any system it runs on. Additionally, it is crucial to understand the path element separator in order to properly set the system environment variables and make sure the operating system can locate the resources needed by the software. system path element separator. : in UNIX-like systems and ; in Windows. |
| ${\n} | The system line separator refers to the character(s) used to separate lines of text in a file. A line separator is used to signal the end of a line of text and the start of a new one. In UNIX-like systems, the line separator is a newline character “\n”, while in Windows, it is a combination of a carriage return “\r” and a newline character “\n”. The line separator is important in software development, as the line separator used in a file must match the line separator expected by the system, in order to ensure that the file can be properly interpreted and processed. Additionally, software developers must ensure that the line separator they use in their code is compatible with different operating systems, to ensure that the code can run on any system it is installed on. |
2 . Number Variables
In Robot Framework, variables can be created for numbers (integers and floating-point). These variables can then be used by keywords that expect numerical input. It is important to note that keywords that require numbers should receive actual numerical values, not just strings that appear to represent numbers.
In Robot Framework, integers can be represented using binary (0b), octal (0o), and hexadecimal (0x) values with case-insensitive prefixes. This allows for a flexible representation of numerical values in test scripts.
example
${80} --> representing integer value 80
${80.09} --> representing floating point value
${0b1011} --> representing binary value of 11
${0o10} --> reprsenting octal value of 8
${0xff} --> reprsenting hexadecimal value of 255
3. Boolean and None variables
In Robot Framework, variables can have either True or False as Boolean values. The value None represents a null or non-existent value, similar to Java’s null variable.
The Robot Framework treats certain values as numbers, making them usable in arithmetic operations. For example, ${True} and ${true} are equivalent, since these variables are case-insensitive. Also, when running tests on the Jython interpreter, None and null are automatically converted to the correct format when required. You can define boolean and none variables as shown below.
${true}
${True}
${None}
${none}
${null}4. Space and Empty variables
In the Robot Framework, empty value variables can be created using ${EMPTY} and spaces using ${SPACE}. It is possible to use multiple spaces by multiplying the value of ${SPACE}, for example, ${SPACE * 5}.
Set Global Variable @{list_variable} @{EMPTY} # Creating empty list
Set Global Variable &{dict_variable} &{EMPTY} # Creating empty dictionary
Set Global Variable ${string_variable} ${EMPTY} #Creating empty string
Note:- The “Set Global Variable” keyword in the Robot Framework is used to set a variable that will be accessible across all sections of a test case. It allows for setting variables that can be reused in different parts of a test case, providing a more flexible and efficient way to manage variables in tests. This keyword is one of the built-in keywords provided by the framework and can be used as part of your test automation strategy.
5. Automatic variables
| Variable | Explanation |
| ${LOG LEVEL} | This variable determines the level of logging that is done by the framework during the test execution. The possible values for this variable are TRACE, DEBUG, INFO, WARN, and ERROR. |
| ${TEST NAME} | This variable stores the name of the currently executing test case. |
| ${TEST STATUS} | This variable stores the status of the most recently executed test case. The possible values for this variable are PASS, FAIL, SKIP, and NOT RUN. |
| ${SUITE NAME} | This variable stores the name of the currently executing test suite. |
| ${SUITE STATUS} | This variable stores the status of the most recently executed test suite. The possible values for this variable are PASS, FAIL, and NOT RUN. |
| ${PREV TEST NAME} | This variable stores the name of the test case that was executed immediately before the current test case. |
| ${PREV TEST STATUS} | This variable stores the status of the test case that was executed immediately before the current test case. |
| @{TEST TAGS} | The current test case’s tags, sorted in alphabetical order, are stored in this variable. It is possible to change the tags dynamically during the execution using the Set Tags and Remove Tags keywords. |
| ${TEST DOCUMENTATION} | This variable holds the documentation for the current test case. The documentation can be modified dynamically during the test execution by using the Set Test Documentation keyword. |
| ${TEST MESSAGE} | The current test case’s message is stored in this variable. This message can be set and updated dynamically during the test execution. |
| ${PREV TEST MESSAGE} | This variable contains the potential error message of the previous test case, if there was any. The message can be accessed and analyzed during the test execution to identify any errors that may have occurred. |
| ${SUITE SOURCE} | This variable stores the absolute path to either the suite file or the directory. It can be used to identify the location of the current suite during test execution. |
| ${SUITE DOCUMENTATION} | The documentation for the current test suite is stored in this variable. It can be updated dynamically during the test execution using the Set Suite Documentation keyword. |
| &{SUITE METADATA} | This variable contains the free-form metadata associated with the current test suite. It can be set or modified dynamically during the test execution using the Set Suite Metadata keyword. |
| ${SUITE STATUS} | This variable stores the status of the current test suite, which can either be PASS or FAIL. It is typically used to determine whether the suite executed successfully or if there were any errors or failures. |
| ${SUITE MESSAGE} | This variable holds the complete message for the current test suite, which includes detailed statistics and information about the execution. It provides a summary of the results of the test cases executed within the suite and can be used to analyze the performance and identify any issues that may have occurred. |
| ${KEYWORD STATUS} | This variable stores the status of the current keyword, which can be either PASS or FAIL. It is typically used to determine whether the keyword executed successfully or if there were any errors or failures. |
| ${KEYWORD MESSAGE} | This variable contains the potential error message associated with the current keyword, if there was any. It can be accessed during the test execution to identify any errors that may have occurred during the execution of the current keyword. |
| ${OUTPUT FILE} | This variable stores the absolute path to the output file. It can be used to identify the location of the output file generated during the test execution. |
| ${LOG FILE} | This variable contains the absolute path to the log file generated during the test execution, or the string “NONE” if no log file was created. It can be used to identify the location of the log file or to check if a log file was created during the test execution. |
| ${REPORT FILE} | This variable stores the absolute path to the report file generated during the test execution, or the string “NONE” if no report file was created. It can be used to identify the location of the report file or to check if a report file was created during the test execution. |
| ${DEBUG FILE} | This variable contains the absolute path to the debug file generated during the test execution, or the string “NONE” if no debug file was created. It can be used to identify the location of the debug file or to check if a debug file was created during the test execution. |
| ${OUTPUT DIR} | This variable holds the absolute path to the output directory used during the test execution. It can be used to identify the location of the directory where the output files, such as the log file and report file, were saved. |
| &{OPTIONS} | This variable is a dictionary that exposes the command line options used during the test execution. The dictionary keys match the command line options and can be accessed using either ${OPTIONS}[key] or ${OPTIONS.key} syntax. The following options are available in the dictionary: ${OPTIONS.exclude} (–exclude) ${OPTIONS.include} (–include) ${OPTIONS.skip} (–skip) ${OPTIONS.skip_on_failure} (–skiponfailure) |
