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.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.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.