The Robot Framework (RF) aims to be an open-source robotic process automation (RPA) ¹ testing solution that users may customize in any way. RF’s key architectural design decisions are based on supporting the following:

Scalability: As RF is free to use without any license payments, anybody can run as many Robot Framework RPA processes as they like in parallel. In enterprise-scale projects, Jenkins ² plugins provide orchestration functionality.
Limitless extensibility through modularity: RF’s extensibility is possible because of its modular design, which is built on top of extension libraries. This allows an autonomous and adaptive development path. The RF community develops and maintains these extension libraries. In addition, it’s simple to create additional libraries using Python or Java, allowing any user to extend the framework’s functionality.
Reusability: Software testing involves validating numerous systems which may be distinct from one another. When designing an automation testing framework, we must ensure that the architecture enables reusability so that multiple types of testing environments may be handled by the same code base.

Context View

To begin analyzing any system’s software architecture, we must first understand the context within which it operates. This includes high-level details about stakeholders and software systems involved rather than technologies or protocols.

Context view ³ for RF has 3 blocks which communicate with each other through APIs and/or data (test data, output data etc.)

Users (QA)
- Quality Assurance personnel who build test suites in the form of .robot files are Robot framework users. They supply keywords to initiate the execution of the needed test and also keep track of the results of the test suites in the form of logs and reports.
System under test (SUT)
- Connected to RF through interfacing libraries (can be inbuilt or can be created using native Python or Java)
RF Automation tool
- The tool which executes test suites based on keywords provided by users. Post validating the system under test it generates web-hosted logs and reports based on the test execution results.

Container View

Container view ⁴ is a representation paradigm where separately running entities exist within a particular application. Each is capable of working on a defined set of tasks.

The RF implementation consists of several containers that work together to implement automation testing. Their workings are in sync with the notion of containers, i.e. units that separately run and execute code. Containers of RF Automation tool consist of the following:

Robot (startup script for executing test cases) Container:

This container is responsible for interpreting the keywords passed by the user to the system. These keywords define properties for the testing process. Upon interpreting these properties the script passes necessary information to the RF Code Base container. For example the test suite to be executed or the output report file directory to be used for storing the log and report file. Furthermore test data obtained from the user is also passed on to the next container.
RF Code Base Container:

This container is the heart of RF’s automation testing ⁵ having necessary libraries, testing suites, utilities, XML testbeds, etc. All this is used to validate the system for the scenarios provided by the users. It is also responsible for interchanging information with extension integration layers in case the required testing needed to be done on a non-native library. For example, Selenium based web automation testing integration layer. Finally, it generates XML outputs that can later be interpreted by other containers to generate results.
Integration Layer + Test Libraries Container:

This container is an addon to the RF Code Base Container. It serves as an interface that extends existing supported robot framework testing libraries. These are usually community driven and include many independently developed integration layers with their necessary test libraries.
Rebot (report and log generator) Container:

This container is responsible for using the XML information it receives from the RF code base container to generate report and log files. It also leverages many HTML and other languages/frameworks to generate efficient and interpretable outputs for the user.

Components and Connector View

To understand more about the components of our system, we concentrate on the “RF Code Base” container. We describe the software’s structural building blocks and how they are interconnected as part of the connector view. Each RF component has its own function and is dependent on input from other components to perform that function.

The components of the RF code base container and their functions are discussed in brief.

Test Suites
- User developed test suites (.robot files) provided through command line arguments are executed on the system under test (SUT) using python calls. The files contain test cases, re-usable functions (keywords), wrapper, object-maps etc.
- Command line arguments provided by user along with robot test script acts as a connector from robot container to test suites component. Another connector is from test suites to application specific utilities and objects passing keywords to execute.
Configuration files
- These constitute the files and libraries required to set up the test environment
- Parses the import statements of .robot files for the external libraries, resources, and the setup and teardown commands.
- Test suites connects to configuration files via API calls to/from conf library.
Application specific utilities and objects
- Testing libraries to parse the keywords for external applications such as Selenium Webdriver, Appium Server etc.
- These RF libraries connect with an integration layer to access the test drivers developed outside of the RF ecosystem.
- Through the integration layer, the test code statements (as written in RFW syntax) are translated into parameterized instructions that adhere to the syntax of the external tool.
- Connectors here are wrapper API calls with test code statements to the integration layers of the respective third party application libraries.
- Another connector with test execution instructions connects to the system under test and receives the observations.
Common Utilities
- Distributed along with RF as a package. They provide support and standard utility libraries for executing generic keywords. For example Android library, Suds library (SOAP-services), SSH library, etc.
- These libraries are developed with an intent of extending the RF and they re-use other open source components of python. The RF HTTP library, for instance, reuses the Python requests HTTP client.
- The connectors here are the respective API calls from application specific utilities and objects to the common utilities providing the keywords to be parsed and the other connector is from the common utilities to the XML Output providing the results of the execution.
XML output
- This component generates an XML output file ⁶ containing test execution results.
- File fetch connector transfers the generated XML Output to the rebot container to generate the final log and report file.

Development View:

The development or implementation view looks at the system in question from a programmer’s perspective. This view is also concerned with the software management aspect of the system.

Amongst the various repositories available as a part of the Robot Framework project, we are going to focus on the main robotframework (automation tool) codebase. In order to execute test suites developed using the robot framework for any application, the only thing that is a prerequisite is having the robotframework package installed using Python’s package management system pip ⁷.

Detailed steps of installation can be found in the INSTALL.rst ⁸. The list of dependencies is minimal because the framework was built in a way to ensure it is operating system and application independent. The test suites can be managed through any text editor. And the execution of the same can be done through any IDE of choice or through the command line corresponding to the operating system in use.

The main constituents of the source directory ⁹ are as follows:

API: Robot Framework’s public APIs are available for other libraries to utilize in order to include the framework’s common functions, such as defining keywords and allowing external libraries to access Robot Framework’s logging and reporting functionality.
Running: This module implements the fundamental test execution logic, which includes running the test suite, interpreting the robot test suites, and executing the keywords.
Results: This module is used during the test execution phase and objects are created internally by the various runners and these objects are then processed further to create an XML output file.
Reporting: This module is used to create log and report HTML files based on the XML output file generated through the results module.
Conf: Implements settings for the test execution phase and output processing. For the execution phase, the conf component processes the CLI inputs and executes the mapped functionality. After the execution of the tests, it collates a list of failed test cases and test suites for further processing like report generation etc.

Run Time View

The runtime view discusses the key scenarios of the system, and how its different building blocks interact with each other in terms of the processes, tasks etc.

The Robot startup script receives and parses the command line options as provided by the QA/user.
The Robot startup script parses the .robot file to obtain the keywords. The keywords corresponding to the test cases are then executed on the system under test.
If external support is needed information is passed to the integration layer, where the keywords are processed and returned back to the RF code base for execution and report generation.
The RF code base creates objects through the test execution phase on system under test which are then used by the reporting module rebot to generate the logs/reports.

Quality Attribute Realization

Robot framework addresses several key quality attributes through its architecture. In this section, we look at some of these and comment on the architectural implementation to address the same.

Usability: RF allows user-defined high-level keywords in its architecture that encapsulates multiple different low-level functionalities. These keywords ensure that the user doesn’t have to work on low-level coding implementation. It aids in improving the usability of the tool.
Reusability: Through its APIs, RF provides a standard entity defining facility for any extension developed over RF. These entities include things like defining keywords or libraries. Hence whether it be Selenium based web automation testing or Appium based mobile application testing, the method of defining keywords or libraries is through standard APIs provided by RF. Hence this facilitates reusability across extensions.
Serviceability: RF provides error logging facility across applications allowing quick discovery of any issues that pop up. The structure of the tool extensions ensures that any maintenance activity being done on one module extension doesn’t affect that of another. Hence making serviceability easier to accomplish.
Modularity: As previously stated, this RF quality is extremely beneficial in the building of test suites, regardless of the platform being tested. Modularity permits the usage of relevant test libraries to be utilized and tested in a seamless manner without many modifications in code.

API design principles

Robot framework is a robotic process automation solution. So the system’s focus is on automation. Additionally the few APIs that have been exposed aim at easy integration of the extensions. They are mainly used by the developers who are working on building the RF extension libraries.

The API documentation currently just lists out the entry points. But the lower level implementation details of the APIs are not well documented. So, after analyzing the source code we are listing a few observations about the API design principles in the framework.

Keyword-driven functionality is the primary premise of Robot Framework, and reusability is one of its important characteristics. The RF API includes Python decorators that may be used by any user-defined library to supply extra keyword parameters that can then be reused in robot files. For example, the decorator keyword(name=None, tags=(), types=()) may be used to give a keyword defined in a user library a custom name, tags, and argument types. Similarly, there are logging and exception handling APIs that can be used by any user-defined library to leverage the built-in RF logging and reporting functionalities.

References:

Robot Framework RPA Documentation (https://robotframework.org/rpa/) ↩︎
Robot Framework Jenkins Plugin (https://plugins.jenkins.io/robot/) ↩︎
C4 Model for visualising context diagram of the software (https://c4model.com/#SystemContextDiagram) ↩︎
C4 Model for visualising container diagram of the software https://c4model.com/#ContainerDiagram ↩︎
Michael Hallik, Robot Framework the unsung hero of test automation - 4th September 2015 https://xebia.com/robot-framework-the-unsung-hero-of-test-automation/ ↩︎
Robot Framework Output XMl Schema https://robotframework-ja.readthedocs.io/ja/latest/schema/README.html#:~:text=While%20Robot%20Framework%20is%20running,files%20using%20rebot%20tool%20internally. ↩︎
Python Package Management System https://pypi.org/project/robotframework/) ↩︎
Robot Framework installation guide https://github.com/robotframework/robotframework/blob/master/INSTALL.rst ↩︎
Robot Framework source directory https://github.com/robotframework/robotframework ↩︎

Robot Framework - A Modular Architecture for Automation Testing