Introduction to Test Automation with Robot Framework


Author	Alena Galysheva
Last Updated	10.03.2025

Test Automation: What, When And Why

Source: What is Automation Testing: Benefits, Strategy, Tools By Shreya Bose at BrowserStack

Automation testing takes software testing activities and executes them via an automation toolset or framework. Simply, it is a type of testing in which a tool automatically runs a set of tasks in a defined pattern. Automated testing implements mundane, repetitive, time-confusing tasks such as regression tests. Automation testing is essential to achieving excellent test coverage within shorter timelines and greater accuracy of results.

Benefits of test automation

Cost Saving: Test automation reduces the need for manual labor, leading to cost savings in the long run as fewer human resources are required for repetitive testing tasks.
Early Bug Detection: Automated tests can be executed quickly on the regular basis, which helps to detect the bugs early on during the development process.
Swift Feedback: Automated test reports document the errors that occurred along with the error logs (and sometimes screenshots), which helps developers to identify and address issues promptly and improve the overall efficiency of the development process.
Better Resource Allocation: Automated tests free up manual testers from repetitive tasks, allowing them to focus on more complex and creative testing activities that require human judgment and expertise like exploratory testing.
Higher Accuracy: Automated tests execute precisely as designed, eliminating human errors and ensuring consistent and reliable test results across multiple test runs.
Faster than Manual Testing: Automated tests execute much faster than manual tests, allowing for quicker validation of changes and faster delivery of software updates to end-users.

Which Tests should be Automated

Generally, the following tests should be considered for automation:

Tests that need to be executed across multiple test data sets
Tests with maximum test coverage for complex functionalities
Tests implemented across multiple hardware or software platforms and on various environments

Types of testing feasible for automation:

Regression Testing: Regression suites are ever-increasing and require the same variables to be filled numerous times to ensure that new features do not tamper with older functions. This can easily be automated.
Smoke Testing: Run automated suites to verify the quality of major functionalities. This saves time by quickly analyzing whether a build requires more in-depth testing.
Data-driven Testing: Automate tests to validate functionalities that must be tested repeatedly with numerous data sets.
Performance Testing: Automate tests that monitor software performance under different circumstances. Doing this manually would be incredibly detailed and time-consuming.
Functional Testing: Every time a developer submits a PR, functional testing needs to be executed quickly and provide immediate feedback. This is impossible to achieve without automation, especially as projects scale up.

Robot Framework

About Robot Framework

Robot Framework (also referred to as RF) is a generic open source automation framework. It can be used for test automation and robotic process automation (RPA).

Robot Framework has an easy syntax, utilizing human-readable keywords. Its capabilities can be extended by libraries implemented with Python. Robot Framework has a rich ecosystem around it, consisting of libraries and tools that are developed as separate projects.

Robot Framework is developed in Finland and popular among local companies, which is why it was picked as the recommended test automation tool in this course.

More about Robot Framework: ROBOT FRAMEWORK ORG

Getting Started with RF

A lot of the following information is copy-pasted from Robot Framework User Guide. It's a great source and I see no point in trying to reinvent the wheel with my writing here. If you want more information on any given RF topic, please read the User Guide.

Note on Virtual Environments

It's recommended to use a virtual environment when working with Robot Framework.

Python virtual environments allow Python packages to be installed in an isolated location for a particular system or application, rather than installing all packages into the same global location. They have two main use cases:

Install packages needed by different projects into their own environments. This avoids conflicts if projects need different versions of same packages.
Avoid installing everything under the global Python installation. This is especially important on Linux where the global Python installation may be used by the distribution itself and messing it up can cause severe problems.

Source: Robot Framework User Guide

Read more about virtual environments in Python here.

Installation

Robot Framework is implemented with Python, so you need to have Python installed.

On Windows machines, make sure to add Python to PATH during installation.

Installing Robot Framework with pip is simple:

pip install robotframework

Restart your device just to make sure the changes are enabled system-wide.

To check that the installation was successful, run

robot --version

For a full guide, please see Installation instructions. It also covers topics such as installing Python on Linux, macOS, configuring PATH, and installing from source.

Now you are ready to write your first tests!

Creating Tests

You can find a simple RF example and playground provided by Robot Framework here.

Folder Structure

.
├── tests - Test Suites folder
│   ├── search.robot - Test Suite for Search functionality
│   ├── login.robot - Test Suite for Log In functionality
│   └── checkout
│       ├── checkout_basic.robot - Test Suites for standard Checkout
│       └── checkout_premium.robot - Test Suites for premium Checkout
├── resources/ - Reusable keywords
│   ├── common.robot - General Keywords (e.g. Login/Logout, Navigation, ...) are stored here
│   ├── search.robot - Keywords for searching are stored here
│   └── variables.py - Python variables
├── libraries/ - Python keyword libraries
│   └── utils.py - Python helper keywords are stored here
├── requirements.txt - Python and RF dependencies
├── readme.md - Project description
├── .gitignore - Lists files and folders to be ignored by git

Depending on the project, the root folder can contain additional files, e.g. .gitlab-ci.yml for a GitLab CI Pipeline.

Test Suites are located in the tests/ folder. Depending on the project, the Test Suites can be organized in multiple .robot files and subfolders.

Reusable keywords are stored in .resource files in the resources/ folder. Also, Python keywords in .py files can be stored there.

Custom Python Keyword libraries can be stored in a separate libraries/ folder, if needed. Some projects like to separate the libraries/ from the resources/.

This is a basic example based on an official example. You can read more about project structure and how to import libraries and resource files here.

Basic Concepts and Definitions

Test Suites

Test suites are collections of test cases grouped together for execution. They provide a logical structure to organize and manage tests related to specific features, functionalities, or modules.

Test Cases

Test cases represent individual test scenarios that verify specific behaviors or functionalities of the system under test. Each test case consists of a series of steps, often composed of keywords, to perform actions and make assertions.

Keywords

Keywords are the building blocks of test cases, representing reusable actions or operations. They can be built-in keywords provided by Robot Framework or user-defined keywords implemented in Python or other supported languages.

Variables

Variables are placeholders used to store and reference values throughout test cases and suites. They allow for dynamic data manipulation and parameterization of tests.

Libraries

Libraries provide additional functionality and keywords beyond what is built into Robot Framework. They can include both standard libraries provided by Robot Framework and custom libraries created by users.

Resource Files

Resource files are external files containing reusable keywords, variables, and settings. They allow for modularization and sharing of common resources across multiple test suites.

Documentation

Documentation provides descriptive information about test cases, keywords, and other elements to improve readability and understanding. It helps testers communicate the purpose and functionality of tests.

Setup and Teardown

Setup and Teardown are special sections within test cases or test suites that define actions to be performed before and after test execution. Setup is used to prepare the test environment, while teardown is used to clean up resources or perform post-test actions.

Arguments

Arguments allow passing dynamic values to keywords or test cases at runtime. They enable parameterization and customization of tests to handle different scenarios or data sets.

Test Suite Structure

Robot Framework data is defined in different sections, often also called tables, listed below:

Section	Used for
Settings	Importing test libraries, resource files and variable files. Defining metadata for test suites and test cases.
Variables	Defining variables that can be used elsewhere in the test data.
Test Cases	Creating test cases from available keywords.
Keywords	Creating user keywords from existing lower-level keywords.

Different sections are recognized by their header row. The recommended header format is *** Settings ***, but the header is case-insensitive, surrounding spaces are optional, and the number of asterisk characters can vary as long as there is at least one asterisk in the beginning. For example, also *settings would be recognized as a section header.

Example test suite would look like:

*** Settings ***
Documentation     Example using the space separated format.
Library           OperatingSystem

*** Variables ***
${MESSAGE}        Hello, world!

*** Test Cases ***
My Test
    [Documentation]    Example test.
    Log    ${MESSAGE}
    My Keyword    ${CURDIR}

Another Test
    Should Be Equal    ${MESSAGE}    Hello, world!

*** Keywords ***
My Keyword
    [Arguments]    ${path}
    Directory Should Exist    ${path}

Hello Robot

Yet again I take others work. I do not present it as my own. This example is taken from Beginners Guide to Robot Framework.

Writing your First Automation Case

Following example shows how to write your first robot automation case:

Create a new file and save it using an extension .robot, for example, my_first.robot.
Write in file *** Test Cases ***. This creates section for test cases.

Type in following (note to add the four spaces before Log To Console)

My First Robot Test
    Log To Console            Hello Robot World!

First test is now ready, and it should look like this:

*** Test Cases ***

My First Robot Test
    Log To Console            Hello Robot World!

Open Terminal/Command Prompt. Navigate to the same folder where your .robot file is located and run the test by inputting command robot my_first.robot. For example:

cd your_folder
robot my_first.robot

When Robot is run, you will see the results:

> robot my_first.robot
==============================================================================
My First
==============================================================================
My First Robot Test                                                   Hello Robot World!
My First Robot Test                                                   | PASS |
------------------------------------------------------------------------------
My First                                                              | PASS |
1 critical test, 1 passed, 0 failed
1 test total, 1 passed, 0 failed
==============================================================================
Output:  /output.xml
Log:     /log.html
Report:  /report.html

Congratulations! You have now run your first test case. Robot has created test report files in the same folder where you run the test.

Viewing Test Results

You can check details of the first test run by opening report.html file.

Running the demo generates the following three result files. These files are linked to pre-executed files available online, but executing the demo creates them locally.

report.html - Higher level test report.
log.html - Detailed test execution log.
output.xml - Results in machine-readable XML format.

Content of the Test Case

Test cases are created from keywords that are ready-made or user written. An example of a keyword is Log To Console, which you used in your first automation case. That keyword was part of the Robot Framework. There is a wide selection of other libraries available, which you can use based on your needs.

Your next automation case will show how to add libraries to Settings section of your Robot file.

Let's add an Operating Systems library to our next example:

***Settings***
Library                             OperatingSystem

Your second test is now ready, and it should look like this. This test will create a new file called new_file.txt:

***Settings***
Library                             OperatingSystem

***Test Cases***

My Second Robot Test
    Create File                     new_file.txt               Hello World!

Run the Robot like in the previous test.

After running the Robot the new_file.txt should contain the text Hello World!.