Understanding And Working With Robot Framework

The Tutorial Explains How to Create & Execute a Basic Test Case in the Robot Framework. You will also learn about Variables & Keywords in Robot Framework:

We learned about the Basics of the Robot Framework IDE – RIDE in our previous tutorial to help us get started with writing test scripts using RIDE in this Robot Framework series.

The tutorial will give you an understanding of the basics of the Robot Framework.

We shall learn about variables and the type of variables available in the Robot Framework. We will see how to create and use the variable. We will also understand what are the keywords along with their various types. We will also get to know How keywords can be created and used.

Besides, this tutorial would also give you knowledge about the Setup and Teardown options in RIDE that is useful in Test case execution. We will also learn about Tags – a feature of RIDE that helps in selective test case execution.

Most importantly, we will be writing the test script (with and without locators) for a few sample test cases. We will learn how these Test scripts are executed in Ride and finally towards the end of the tutorial we will learn to view the reports for the executed test scripts.

We will be concluding the tutorial with some helpful links on the Robot Framework that you can refer to anytime.

Creating And Executing A Basic Test Case

Let’s now create a basic test case in the RIDE where we shall be opening the website google.com in the Chrome browser and then we shall be closing the browser. So let’s get started with our first test case in Robot Framework using Ride.

Click on ‘TestCase1’ and you can see a grid (you should be on the ‘Edit’ tab).

Follow the below steps to write the code:

• Type ‘Open Browser’ (keyword provided by Selenium Library) in the first cell.
• As you start typing, select ctrl+ alt+ spacebar (or ctrl+ spacebar) to get Content assistance.
• In the next cell type the URL Google.
• In the third cell type the browser name. Providing the browser name is optional.
• In the first cell of the next row type ‘Close Browser.

Let’s understand what we have just done.

• ‘Open Browser’ is a Keyword provided by the Selenium library that we imported above in our test case.
• Content assistance helps us with the exact syntax without having to remember it.
• ‘Open browser’ takes the first argument as the URL of the site that we want to open in the browser. The second argument is optional and it specifies the browser that we want to use. If this is not mentioned then Firefox is used as the default browser.
• “Close Browser” is again a Selenium Library keyword that closes the browser we opened.

Now we shall execute this code by following the steps below:

• Click the ‘Run’ tab – This tab contains the option to execute the test case.
• Check ‘Autosave’ – To ensure any unsaved changes to the test case are automatically saved.
• Check ‘TestCase1’ – To let RIDE know which test case we wish to execute.
• Click the ‘Start’ button – To start the test case execution.

The test case gets executed successfully. Below is the screen that we get after the successful execution of the test case. Here, we can see the total time taken for test execution along with the count of passed and failed test cases.

Besides this, we also have the option to view Report and Log for the executed test case. We shall see that in the upcoming tutorials.

Understanding Variables In Robot Framework

Just like any programming language where we use variables, similarly, we also have variables in the Robot Framework.

What are Variables?

Variables are nothing but storage locations referred to by a name that contains some value.

Types of Variables

In Robot Framework we have 3 types of variables:

1. Scalar
2. List
3. Dictionary

In the next two topics, we shall see how each of the above types of variables can be created and used.

Creating Variables

In Robot Framework the variables are not case sensitive. We should use the upper case letters to refer to global variables (that are used across the entire set of test cases) and lower case letters to refer to local variables (that are used in certain test cases only).

To name a variable, we used a variable type identifier (&,%,$, @) that precedes the variable name written within curly braces. Let’s take a look at how each of the variable types is declared.

#1) Scalar Variable: A scalar variable is referenced as ${Name}.

Here, $ – refers to the variable type i.e. Scalar Name – is the variable name.

As a rule, this is placed within curly braces. A scalar variable can be provided with any value, for instance, a string, an object, numbers, lists, dictionaries, or custom objects.

Let us assign value 5 to the scalar variable ‘a’.

Follow the steps below to do so:

TestCase1 (right-click) -> New Scalar

You get a pop-up screen as shown below:

Enter the variable name within the curly braces as seen in the snapshot above. Provide its value in the ‘Value’ text box and add a comment if you would like to.

This scalar variable – ${a} we just created can now be seen in the left panel.

#2) List Variable: A List variable is referenced as @{name}.

Here, @ – refers to the variable type i.e. List name – is the variable name. As a rule, this is placed within curly braces.

The list allows a Python list or list-like object to be stored in it. Robot Framework does not allow strings to be used as lists, but objects such as tuples or dictionaries are allowed.

Let us assign values ‘Hello’, ‘Robot’, and ‘Framework’ to list variable ‘b’. Follow the steps below to do so:

TestSuite1 (right-click) -> New List Variable

You get a pop-up screen as shown below. Instead of the default ‘4’ in the columns drop, we will select ‘2’.

Now follow the below steps:

• Enter the variable name ‘b’ within the curly braces as seen in the snapshot below.
• Provide its values in the ‘Value’ text box.
• Add a comment (optional).
• Click ‘OK’ to save the variable.

Each of the values within the list variable is accessed relative to its index which is considered from 0 for the first value in the list. For Example, to refer to a Framework we would write it as @{b}[2], as it is at position 3 for which the index would be 2.

#3) Dictionary Variable: A dictionary variable is referenced as &{Name}.

Here, & – refers to the variable type i.e. Dictionary Name – is the variable name. As a rule, this is placed within curly braces.

Dictionary variables are mainly used when we have a table with Key-value pairs. For instance when we want to test login for a set of IDs and passwords. The difference between the List and Dictionary variables is how they are referred and we shall see that going forward.

Let us create a dictionary variable ‘login’ and assign values: email and password to it as shown below: ‘testingrf19@gmail.com’, ‘123’. Follow the steps below to do so:

TestSuite1 (right-click) -> New Dictionary Variable

You get a pop-up screen as shown below. Instead of the default ‘4’ in the columns drop, we will select ‘1’.

Now follow the below steps:

• Enter the variable name ‘login’ within the curly braces as seen in the snapshot below.
• Provide its values in the ‘Value’ text box.
• Add a comment (optional).
• Click ‘OK’ to save the variable.

Unlike List variables that use the index for referencing the individual values within it, Dictionary variables use a more clear way to reference their values. As in the case above we would use &{login}[email] and &{login}[password]. Does this not look quite self-explanatory?

These created variables are also visible in ‘TestSuite1’ (Edit tab).

Using Variables

We shall now see how we can use these variables within our test case. We will be using the Test case created earlier and replace the URL used with a variable that will store the URL instead. So let us create a scalar variable named ‘URL’ and store the value Google in it.

We will now replace the URL with the variable in our code. As this is a scalar variable, it will be referenced as ${URL}. Our test case should now look as shown below:

Let us Run this test case and see if the variable ‘URL’ gets replaced with the correct value. Yes! Our test case gets executed successfully. Google.com opens in the browser and then the browser closes. The result shows that it was a success.

The green symbol beside the test case name on the left panel and PASS on the right panel shows that the test case execution was successful.

This is how we use variables within a test case. The benefit of using variables is visible when we are using the same value at multiple places. Whenever there is a change in the value, we would only need to replace the value of the variable and the same would get reflected at every place where the variable has been used.

Similarly, we can use the List as well as the dictionary variable as required within our test cases.

Understanding Keywords In Robot Framework

What are Keywords?

Keywords as the name imply (‘Key’ + ‘word’) is a word serving as a key to something not in view. More simply let us understand that if I have a task with 10 steps to be done and I mention those 10 steps and refer to them by a name then the name is a keyword.

Types Of Keywords

Robot Framework provides two types of keywords:

• Library Keywords: These keywords are also known as low-level keywords. These are made available by the libraries used with the Robot Framework (Builtin and External libraries). For Example, we have a Keyword “Log to Console” that is provided by the Builtin library, and “Open Browser” is a keyword provided by the Selenium library.
• User-defined Keywords: These are also known as high-level keywords. They are defined by the user. User-defined keywords could also contain other Library keywords and/or other actions as well.

Creating Keywords

This tutorial will explain the ways to create user-defined keywords.

Right-click ‘TestSuite1’ and select ‘New User Keyword’.

You would get a screen pop-up as below. Let us create a keyword to open the Google website. So we would have just one keyword to perform the task of the test case that we had created.

Open the test case you created and look at the steps you added. We opened google.com in Chrome and then closed the browser.

Let us give the name ‘Open google’ to our keyword and click ‘Ok’.

The keyword has been defined and now the actions that need to be performed will be written within this keyword. So click ‘Open Google’ and write the same steps that we wrote in our TestCase1.

As you see below, the keyword “Opengoogle” would open google.com in the Chrome browser and then exit the browser.

Using Keywords

We now have defined our keyword “Open Google”. It is pretty simple to use it in our test case. First, take a look at our original test case that we had created for opening google below.

We shall now replace this code with the keyword. You will notice that as you begin typing the keyword and open the content assistant, this keyword will also be visible within the list that shows up. Look at the screenshot below.

Once replaced, our TestCase1 would look simple as shown below:

Let us execute this and see if it works as intended.

Yes! the test case passes and we have the expected result.

Using Setup And Teardown In RIDE

Just as the name suggests, Setup is the set of instructions/keywords that are to be executed as initial preparation for executing the actual test case. As an example, generally for any test case execution, our basic requirement would be to open a browser. So we can always add this step of opening the browser as a Setup activity.

Similarly, tear down are the set of instructions/keywords that are to be executed at the end of a test case execution. As an example, when we finish executing a test case, we would want to close the browser. So we can always add this step of closing the browser as a teardown activity.

Setup and Teardown activities can be declared at:

• Test suite level: When declared at the test suite level the setup instructions will be executed before any of the test cases within that test suite are executed. Similarly, tear down declared at the test suite level would get executed after any of the test cases within that test suite is executed.
• Test case level: When declared at a test case level the setup instructions will be executed before the execution of the test cases within that test suite are executed. Similarly, a tear down declared at the test case level would get executed after the test case is executed.

Let’s now see how we add a setup activity at the Test Case level.

• Create TestCase2.
• Click the ‘Edit’ button for Setup, just below Settings in the right panel.
• Type in the keyword, “Open Browser” in our case. You can use the content assistance here too.
• Arguments can be passed along with the keyword by separating them with a ‘|’ pipe sign.
• Click ‘OK’.

Let us now see how we add a tear-down activity at the Test Case level.

1. Click TestCase1
2. Click the ‘Edit’ button for tear down, just below Settings in the right panel.
3. Type in the keyword, “Close Browser” in our case. You can use the content assistance here too.
4. Click ‘OK’.

Now that we have moved both the steps of the test case as set up and tear down activity, let us add one more step to the test case so that we could execute and check its result. Let us display “Hello” on the console. The keyword we have used is ‘Log’ which is from the Builtin Library.

TestCase2 would look as shown below:

When it is executed, the Setup is executed first, followed by logging ‘Hello’ on the console, and finally, the teardown activity is executed and the browser closes.

Using Tags In RIDE

Tagging is used when we want to group a set of test cases either to execute them or to avoid their execution. We mainly group tests under Regression, Smoke, and Sanity. Or it could be in scenarios where some important functionality needs to be tested repeatedly.

To understand how tags are created and used, let us write two simple test cases – ‘TestCase3’ and ‘TestCase4’. The code for this is shown below. We have used the keywords, ‘Log to Console’ which is from the Builtin library.

Test Case 3

Test Case 4

To tag these test cases, follow the steps below:

• Click the Edit button for ‘Tags’.
• On the pop up enter a name for the tag, and say Case3.
• Click ‘OK’

Both the test cases now have the tag ‘Case3’. Let’s see how this can be put to use.

Suppose we wish to execute only testcase3 and testcase4.

• Goto RUN tab
• Check the box ‘Only run tests with these tags’

• In the text box below, type ‘Case3’.
• Click the start button.

Note that we did not select any test case but after the test execution you will see that only ‘TestCase3’ and ‘TestCase4’ have been executed.

Similarly, we also have the option of skipping particular tagged test cases using ‘Skip tests with these tags’ and mentioning the tag name.

We also have the option for creating tags dynamically at run time using the keyword “Set Tag”, similarly we can also remove tags at run time using the keyword “Remove Tag”.

Hope this tutorial has given you a clear idea of creating and using tags by now.

Creating Test Case Using Locators

We created a very basic test case that involved writing something on the console or just opening a browser. Let us now write test cases that involve the use of locators.

Testing a website or any application involves locating the elements. When we want to perform an action on any element, we need to know its locator. Normally the ‘id’ or the ‘name’ are the attributes of an element that are used to identify it on a page and hence perform an action on it using keywords.

We shall open a browser and search for the Robot Framework official website and open it.

Let’s get going and write the code for this.

• Create ‘TestCase5’ within the TestSuite1.

• Open Browser (Chrome).
• Next, find the locator of the google search text box.

Chrome Settings -> Tools -> Developer Tools.

The same can also be accessed using Ctrl + Shift + I.

• With the developer tool open, click the locate element icon as indicated below.

• Hover it over the google search text box till it gets highlighted and clicks over it. You will notice that the code related to the search box gets highlighted on the right panel.
• From the code, we will use the name=’q’ as the locator.
• ‘Input text’ is the Selenium keyword to be used to enter text in the google search box.
• Press the Enter key to get the search results.

This is how our code would look. It looks pretty simple!! Isn’t it?

It is all about practice. All we need is, to be able to recall which keyword is available to automate a particular action. So, the more you automate your tests, the more comfortable you would get working with this Framework.

The result of the above test case after execution is shown below. The chrome browser is seen open below by showing the search results for the ‘Robot Framework’.

Understanding Keyword And Data-Driven Approach In Robot Framework

When writing a test case in Robot Framework, we follow either of the below approaches:

• Keyword-Driven Approach: When we use keywords in writing the test cases we call it a keyword-driven approach. The keyword-driven approach improves the readability of the test case. We have already seen how keywords can be created and used in a test case.
• Data-Driven Approach: This approach is mainly followed when we want to test logic for different data values. In this approach, a template is created for a high-level keyword, and the arguments to this keyword are sent from the test case which is the data value for which the test case needs to be executed.

How we use this approach in our test cases is what we will see below as we create a new Keyword.

Let us create a test case for searching for different Test automation tools/frameworks – Robot Framework, J-meter, Selenium, etc.

The test case would just contain the data, in this case, the search words that would be passed as arguments to the template. The template would contain the high-level keyword that would have the actual code to be executed. The search values would be written in the test case.

With this brief understanding let us create the Template ‘Google Search’ by following the below steps:

• Create TestCase6 as explained in the topic “Creating a Project, Test Suite and a Test Case in Ride”.
• Click ‘Edit’ for Template and enter a name. ‘Google Search’ in our case.

• We will use the same code as in TestCase5, with the only difference being that the text to be searched will be passed as an argument as pointed below.

• This argument is also to be mentioned in the Argument text box. So click Edit in the Arguments text box and enter the argument and click ‘OK’.

• Now let us get back to TestCase6 and enter the data.

• This is what your screen will look after the test case execution is completed.

You will notice that five instances of the Chrome browser have opened and each would have the search results for the five different test automation tools that we have searched.

We hope this test case has given you good clarity on the Data-driven approach. As you try your hands on more such examples this approach would seem quite simple to you.

Accessing Reports in Ride

Given below is the screenshot after TestCase6 is executed. It provides 2 options ‘Report’ and ‘Log’ as indicated below. It also provides the complete link to access the Log and Report.

Report – TestCase6 execution result

It gives a summary report of the Test suite(s) executed. On clicking the Test suite, it shows the details of the test suite, Test case wise. When we further click the test case, it opens up the details of the test case which is called the Log.

Log – TestCase6 execution result.

The log gives a detailed report test case-wise for the entire Project.

Besides the Report and Log icons. We also have the URL’s of these that can be copied and opened directly in the browser. It is a known issue that sometimes after running a test case the ‘Report’, ‘Log’ icons are disabled. In such a scenario, these links can be copied and opened in the browser to view the Report.

The URL is the location in the local machine where the reports are saved. Every time we execute a test case this location gets refreshed and the new report generated gets saved at this location.

Robot Framework – Useful Links

• Robot Framework official website
• Wikipedia

Conclusion

We hope as a beginner this tutorial would have provided you with good knowledge on the use of Robot Framework as a Test Automation tool.

In this tutorial, we learned about the creation of variables and keywords. We saw how to write test scripts using Keyword driven and Data-driven approaches.

We also did a hands-on test script execution. The tutorial gave an insight into viewing the detailed test results via log and Reports. Besides that, important URLs related to Robot Framework have also been shared.

“Practice makes a man perfect”, so without any delay bring this tool into use as much as you can so that you can gradually become confident in using it.

Happy Reading!!

PREV Tutorial | FIRST Tutorial