Copyright 2025 ArcTouch
ArcTouch provides step-by-step instructions how to use Robot Framework for test automation after implementing it on the TDN website.
5 min. read - February 18, 2021
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).
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.
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:
1
Using a non-keyword framework, it would be necessary to write something like:
1
2
3
4
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.
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
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Home_page.robot:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
The resources folder has all common functions, actions, and libraries. I created a file with the name base.robot:
1
2
3
4
5
6
7
8
9
10
11
12
13
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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.
To automate this scenario using Robot, we need to do these things:
Import the SeleniumLibrary:
1
2
Input the variables:
1
2
3
4
5
6
7
8
9
Fill the test cases field:
1
2
3
4
5
6
7
Implement the keywords behavior:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Last, we execute this command in the terminal:
1
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 to scale your app development or web projects with DevOps engineering? Contact us to set up a time to talk.
Get our newsletter in your inbox.
ArcTouch shares 12 best practices that provide a great starting point for building accessible web experiences.
5 min. read - April 16, 2024
The ArcTouch design and development team shares how to use AI to build lovable apps and websites — better and faster.
5 min. read - April 9, 2024
We help companies of all sizes build lovable apps, websites, and connected experiences.
