How to use Robot Framework for test automation

In our product development team’s quest to continually improve our testing and QA process for apps and websites, we’re always eager to try new tools. That means we do a lot of experimentation. When we find something we love that solves a real problem — we start using it for our client’s projects.

In this post, I’ll share step-by-step instructions on how we implemented Robot Framework test automation as part of our ongoing DevOps engineering services for The Draft Network (TDN).

TDN web project: Short timeline, frequent updates

As we wrote in a blog post about our initial DevOps work for TDN, “The web development team needed the ability to continuously improve and update the site without downtime. The back-end needed to support the growth of new accounts and surges in website traffic.”

Our DevOps system made updates easy. But one area we wanted to improve was the time required to test those updates. The answer: automated testing.

Previously, our bi-weekly “smoke test” to check new functionality and content would take an entire day. We knew we could improve this with test automation — and also continue to increase the overall performance of the website. We just had to decide which test automation framework to use.

Why use Robot Framework for test automation?

Our goal was to fully deploy test automation in 45 days. In that short period, we had to create the framework and also teach the QA analysts how to use it (including the client’s internal team). We needed a framework that was easy to configure and understandable. I quickly built some proofs-of-concept using a few different frameworks, including our own ArcTouch Python test automation framework, Ruby/Capybara, and the open-source Robot Framework. I shared these with our team and we decided to proceed with Robot Framework.

A primary benefit of the Robot Framework is simplicity and a short learning curve. Even developers with limited experience with test automation can understand the framework’s low-code approach. Given the short time frame and desire to ramp up team members quickly, this was a key to our decision-making process.

Robot’s code is keyword-based and uses action words that resemble natural language, and less like programming. For example, if the user wants to open a browser the keyword command is:

Open Browser safari www.staging.arctouch.com

Using a non-keyword framework, it would be necessary to write something like:

public void openBrowser{
  driver = new Driver("Safari");
  driver.get("www.staging.arctouch.com")
}

After choosing the framework, we implemented it for TDN. I can’t share the specific code from the TDN project — but here are the basic steps to use the Robot Framework for test automation on a typical website.

Step-by-step: Using Robot Framework test automation

Step 1: Create test scenarios

After your automation strategy is clearly defined, the first step to applying Robot Framework is to create test scenarios.

Imagine a basic Login web page with two fields (email and password), a sign-in button, and the title “Login.” When the user types valid credentials, the home page is displayed with the message, “Welcome to our home page.”

To start, reference the Robot Framework SeleniumLibrary, which will provide keywords you’ll need.

Then, we use a behavior-driven development methodology to write our test scenario, like this:

Scenario: The user access the Home screen   Given the website displays the “Login” screen      And the user inserts “valid@email.com” in the email field      And the user inserts “123456” in the password field   When the user clicks on the “SignIn” button     Then the website should display the “Home” screen        And the website should display the “Welcome to our Home page” text

Step 2: Organize project with page objects

All of your code can be in a single file, but imagine how many times it would be necessary to execute the login before a test? Or, how many times will it be necessary to access the page? If the code remains in one big file, any login page changes will need to pass in all test scenarios refactoring it. So, we use page objects to make automated testing more modular.

It is also important to point out that using page objects — even though it is not exclusive to the Robot Framework — will help you mold a great structure for your automation project.

Here’s how to use a page object model to organize the project environment. First, divide your workspace into your primary folders. For example, let’s use: features, pages, resources, results, and steps.

The features folder has all test scenarios written in gherkin. All files in this folder are labeled with <page_name>_tests.robot. In this example, we create the file Login_tests.robot:

***Settings***
Resource ../resource/base.robot
Resource ../steps/Login_steps.robot
Test Setup base.New session
Test Teardown base.Close session

***Test Cases***
Scenario: The user access the system
Given the website displays the "Login" screen
  And the user inserts "valid@email.com" in the email field
  And the user inserts "123456" in the password field
When the user clicks on the "SignIn" button
  Then the website should display the "Home" screen
    And the website should display the message "Welcome to our Home page" text

The pages folder now has all pages with their components, locators, and main functions. All files in this folder use this naming convention: <page_name>_page.robot. In this example, we create two files, Login_page.robot and Home_page.robot:

Login_page.robot:

***Settings***
Resource       base.robot
Test Setup     base.New session
Test Teardown  base.Close session

***Variables***
  ${loginTitleLocator}     id=loginTitle
  ${emailLocator}          id=emailField
  ${passwordLocator}       id=passwordField
  ${signInButtonLocator}   id=signInButton

***Keywords***
Login page is presented
  Wait Until Element Is Visible      ${loginTitleLocator}
  Wait Until Element Is Visible      ${emailLocator}
  Wait Until Element Is Visible      ${passwordLocator}
  Wait Until Element Is Visible      ${signInButtonLocator}

Insert ${email} in the email field
  Input Text   ${emailLocator}   ${email}

Insert ${password} in the password field
  Input Text   ${passwordLocator}   ${password}

Click on the signIn button
  Wait Until Element Is Enabled.  ${signInButtonLocator}
  Click Button                    ${signInButtonLocator}

Home_page.robot:

***Settings***
Resource         base.robot
Test Setup       base.New session
Test Teardown    base.Close session

***Variables***
  ${homeTitleLocator}       id=homeTitle
  ${welcomeMessageLocator}  id=welcomeMessage

***Keywords***
Home page is presented
  Wait Until Element Is Visible   ${homeTitleLocator}
  Wait Until Element Is Visible   ${welcomeMessageLocator}

Message in the message area should be   ${expected_message}
Element Text Should be                  ${welcomeMessageLocator}  ${expected_message}

The resources folder has all common functions, actions, and libraries. I created a file with the name base.robot:

***Settings***
Library         SeleniumLibrary

***Variables***
${URL}          www.login-example.com
${browser}      headlesschrome

***Keywords***
New session
  Open Browser    ${URL}   ${browser}

Close session
  Close Browser

In the results, all files (screenshots, logs, and reports) created during the automated test execution are archived:

In the steps folder, you can see what each step does and what keywords are used to execute the steps. All files in this folder are named using <page_name>_steps.robot. In this example, I created Login_steps.robot:

***Settings***
Resource      ../steps/Login_page.robot
Resource      ../steps/Home_page.robot

***Keywords***
the website displays the "Login" screen
  Login_page.Login page is presented

the user inserts "${email}" in the email field
  Login_page.Insert ${email} in the email field

the user inserts "${password}" in the password field
  Login_page.Insert ${password} in the password field

the user clicks on the "SignIn" button
  Login_page.Click on the signIn button

the website should display the "Home" screen
  Home_page.Home page is presented

the website should display the message "${expected_message}" text
  Home_page.Message in the message area should be ${expected_message}

In this example, you could easily add new tests for scenarios for when users enter incorrect credentials using most of the same code — saving time and effort.

Step 3: Automate the test scenarios

To automate this scenario using Robot, we need to do these things:

Import the SeleniumLibrary:

*** Settings ***
Library   SeleniumLibrary

Input the variables:

*** Variables ***
${URL}                    www.login-example.com
${browser}                headlesschrome
${loginTitleLocator}      id=loginTitle
${homeTitleLocator}       id=homeTitle
${welcomeMessageLocator}  id=welcomeMessage
${emailLocator}           id=emailField
${passwordLocator}        id=passwordField
${signInButtonLocator}    id=signInButton

Fill the test cases field:

Scenario: The user access the system
  Given the website displays the "Login" screen
    And the user inserts "valid@email.com" in the email field
    And the user inserts "123456" in the password field
  When the user clicks on the "SignIn" button
  Then the website should display the "Home" screen
    And the website should display the message "Welcome to our Home page" text

Implement the keywords behavior:

***Keywords***
the website displays the "Login" screen
  Open Browser ${URL} ${browser}
  Wait Until Page Contains Element ${loginTitleLocator}

the user inserts "${email}" in the email field
  Input Text ${emailLocator} ${email}

the user inserts "${password}" in the password field
  Input Text ${passwordLocator} ${password}

the user clicks on the "SignIn" button
  Click Button ${signInButtonLocator}

the website should display the "Home" screen
  Wait Until Page Contains Element ${homeTitleLocator}

the website should display the message "${expectMessage}" text
  Element Text Should Be ${welcomeMessageLocator} ${expectMessage}

Last, we execute this command in the terminal:

robot login_test.robot

Using Robot Framework on a client project

We learned a lot from using Robot Framework on a client project. Here are a few takeaways:

• Plan to create lots of user scenarios. As I developed different scenarios for our project, I came across countless edge cases — and I had to adapt the code frequently as I found new ones. In our project, we created 54 total test scenarios.

• Expect integration challenges: From the moment we deployed the Robot Framework to run on our continuous integration platform, our tests started to break. Turns out, it was because of the server configurations we were using. This framework has specific server requirements you need to meet when building the structure.

• Page objects save time: Using the page objects methodology, all keywords can be reused in other test scenarios, and the time spent creating new tests is reduced.

• Robot Framework lives up to its promise: It proved to be relatively simple to configure the Robot environment and easy to implement the tests.

Most importantly, here’s the ROI that TDN saw by using Robot Framework test automation: Our test execution time dropped by 50 percent. We saved ourselves — and our client — a lot of test time with every future release, and increased the site’s quality.

Need help with your DevOps?

Need to scale your app development or web projects with DevOps engineering? Contact us to set up a time to talk.