Robot Framework: a test automation rainbow cake

Publish date:

Unlock the functionality of different test libraries or define and reuse your own testcode; Robot framework offers a rainbow of possibilities!

Robot Framework is worth a party, and there is no party without rainbow cake! Robot Framework is a keyword-driven test automation framework. Keywords are readable words that describe a set of actions that need to be executed. Existing keywords are available in Robot Framework to unlock the functionality of different test libraries. New keywords can be created on different levels to define and reuse your own test code. Combining existing keywords or creating new keywords, both high-level in domain specific language or low-level in Python, everything is possible.

But with great power comes with great responsibility. When you work with several people on a test set without a clearly agreed structure, it is easy to get lost in a labyrinth of keywords. Structure is a must to keep a Robot Framework test set maintainable, and can be achieved by a layered cake of test automation. This article covers the implementation of a multi-layer test automation architecture in Robot Framework, writing BDD testcases and using the Page Object Model to automate on the GUI level.

The picture below shows the layered test automation architecture in Robot Framework. It improves the maintainability of automated tests by decoupling testcases from the implementation of the tests and interaction with the application under test. This means that a change in the application under test must only be adjusted in one place, instead of all test scripts using this component.


A feature file contains the testcases of a feature and optional tags to categorize the tests. With Robot Framework, it’s possible to write testcases in domain-specific language using the Gherkin format (Given/When/Then). This provides a compact structure for testcases and makes it readable for the business. Unfortunately, in Robot Framework it is not yet possible to use Given/When/Then prefixes in your own language.

Writing relevant Gherkin testcases on the right granular level is an art on its own. When all actions are written out in the testcase (input in fields, buttons that get clicked), the overview soon gets lost and the goal of the test becomes unclear. Only state the situation and actions that determine the outcome of the test. What helps me is to start with the “Then” step, which comprises the actual goal of the test. From there, I reason back to the determining action (When) and the situation (Given). I aim for testcases with a maximum of four sentences.

Tags come in very handy when categorizing or selecting tests to run. When executing Robot tests via the command line, it is possible to include or exclude those tags. This is particularly handy when you want to integrate your tests in a CI/CD pipeline. Tags can be stated per testcase or for a whole feature file (default tags). In the example below, all testcases in the “Login_feature” file will have the tag “Login_feature” and only the testcase will get an extra “Smoke” tag.


Every sentence of the Gherkin test starting with a Gherkin prefix (Given/When/Then/And/But) is a keyword in Robot Framework. These prefixes don’t need to be repeated in the step implementation. This means that in the example “When I log in with valid username and password,” the steps can be implemented without stating “When” in the keyword. In that way, this step can be used with all prefixes.

Implement the actions needed for every step of the Gherkin test. In order to decouple the tests from the implementation, there should be no interaction here with the application under test. The rule of thumb is that all actions refer to keywords in the helpers; there the interaction with the application under test takes place. This means that test libraries are not needed in the step file. An exception might be a library to generate test data (faker library).

Variables in the steps are typically a form of test data and should be appointed in the variables section at the top in order to keep the overview. Improve readability and reusability by describing understandable variables. Don’t just state a random username but state the situation of that variable (valid/invalid for example). Put variables in a global variable file when they are used in multiple step or feature files and include “global” in the variable name so the scope is clear.

Once a step is implemented, it can be reused in other feature files. In Eclipse and IntelliJ, you can use a shortcut for basic node completion (Ctrl + Space) in order to see all available steps.


Keywords in the helper file describe actions via a test library to interact with the application under test. Which test library to use depends on the level of the application under test you want to interact with. In this example, the SeleniumLibrary is used to create an automated GUI test.

Page Object Model
The Page Object Model pattern is a known GUI test automation strategy and a way to structure helper files. Every helper file contains all interactions of one GUI page. This means several step files can use this implementation and when a change in the GUI occurs, it only needs to be adjusted in one place. That is why it is important to make the keywords in the helper file as generic as possible. The implementation of “inputUsername” in the example is made generic by the input variable. In this way it can be reused in steps with different sorts of test data, when testing with invalid credentials, for example. The same keyword in the helper can be used, only the test data (in the step file) changes.

Variables in the helpers are typically locators of elements and should also be appointed in the variables section in the top. Before interacting with an element in Selenium (click/select/input), it is good practice to first wait until the element is visible. This might feel like overkill but prevents instable behavior in the test.

In this example, I showed the implementation of the test in the GUI, but there are many other possibilities. For an internal DevOps project, I created both API and GUI tests in Robot Framework, using the same test automation architecture. Only the helper was different for the API test. I tagged the tests, so I could integrate several small testing steps in a Jenkins pipeline. This shows great flexibility in the tool enabling futureproof test automation fit for continuous testing.

In order to maintain a test set in Robot Framework and any other keyword-driven framework, structure is the key. The layered test automation architecture is a known strategy and enables the decoupling of the testcase with the implementation. In that way you will notice that the cake remains manageable. Just follow the recipe, put one layer on top of the other and find out what works for you. Whether you frost it or not is up to you!

Related Posts


Zombies, wizards, werewolves, and a test automation silver bullet

Grant Volker
Date icon November 21, 2019

Expectations of technology have dramatically changed over the years, creating a demand for...

Bruce Lee Driven Developments

Continuous testing: do it like Bruce Lee!

Anaïs van Asselt
Date icon June 10, 2019

“Testing is the key bottleneck standing in the way of truly implementing DevOps and...


Challenges in implementing test automation

Maurice Siteur
Date icon November 30, 2018

We conducted a research about implementing test automation within the organizations. Read...