{{announcement.body}}
{{announcement.title}}

How to Write Data Driven Tests With Robot Framework

DZone 's Guide to

How to Write Data Driven Tests With Robot Framework

In this second part of the series about Robot Framework, we are going to explore Data Driven Tests. The Data Driver Library can cope with large datasets. Enjoy!

· DevOps Zone ·
Free Resource

In this post, we are going to explore how to write data driven tests with Robot Framework. We will take a look at how data driven tests can be written with standard Robot Framework syntax and we will take a look at the Data Driver Library which offers some interesting features.

1. Introduction

In our previous post, we looked at some basic concepts of Robot Framework. This time, we will explore how to write data driven tests with Robot Framework.

We will continue using the examples of our previous post, it is therefore advised to take a look at that post but it is not required if you already have knowledge of the basic Robot Framework concepts. The source code used in this post can be found at GitHub.

2. How to Write Data Driven Tests

Data driven tests allow us to repeat the same test over and over again but with different input and/or output data. Of course, we can write separate test cases in order to accomplish this, but data driven tests will make this more concise, less error prone and more clear.

We will explore some of the capabilities by means of the demo application of our previous post. We created an employee.py Python script which allows us to add an employee to a CSV file, to retrieve the list of employees and to remove the entire list of employees. We also created a Robot Framework test script employee.robot for this. One of the test cases verifies whether adding an employee functions properly.

Python
 




x


 
1
| Add Employee                  | [Documentation] | Verify adding an employee
2
| | [Setup]                     | Clear Employees List
3
| | Add Employee                | first_name=John | last_name=Doe
4
| | ${output} =                 | Retrieve Employees List
5
| | Should Be Equal             | ${output}       | ['John Doe']
6
| | [Teardown]                  | Clear Employees List


The test contains the following steps:

  • We clear the entire list of employees in the Setup;
  • We add an employee John Doe to the list;
  • We retrieve the list of employees and verify whether the employee has been added to the list;
  • We clear the entire list of employees again in the Teardown in order to restore the list of employees to its initial state.

2.1 The Standard Robot Framework Way

Let’s assume we want to verify whether adding an employee also works fine for other employee names. We therefore need to rewrite our test case as a keyword in order to be used as a template for input data. The test remains the same, we only need to change it to accept the data as arguments and use the arguments in our tests. We also have to remove the Setup tag at the beginning of the test. Setup is not supported in keywords, see here for the explanation why.

If you do use Setup in a keyword, the following error is raised:

Shell
 




xxxxxxxxxx
1


 
1
[ ERROR ] Error in file '.../MyRobotFrameworkPlanet/test/data_driven.robot' on line 24: Non-existing setting 'Setup'.


The Add Employee Template keyword which contains the test, is the following (the data_driven.robot file in the test directory of the repository contains the full contents of the test script):

Python
 




xxxxxxxxxx
1


 
1
| Add Employee Template         | [Documentation] | Template for verifying adding an employee
2
|                               | [Arguments]     | ${first_name}
3
|                               | ...             | ${last_name}
4
| |                             | Clear Employees List
5
| | Add Employee                | first_name=${first_name} | last_name=${last_name}
6
| | ${output} =                 | Retrieve Employees List
7
| | Should Be Equal             | ${output}       | ['${first_name} ${last_name}']
8
| | [Teardown]                  | Clear Employees List


The template keyword takes the first_name and last_name as arguments and the hard coded values for John Doe are replaced with the argument values.

The Add Employee test only contains the Template tag which refers to the keyword which has to be used as a template for the data driven test. The remainder of the test case consists of the data we would like to test.

Python
 




xxxxxxxxxx
1


 
1
| Add Employee                  | [Documentation] | Verify adding an employee
2
| | [Template]                  | Add Employee Template
3
| | first_name=John             | last_name=Doe
4
| | first_name=Monty            | last_name=Python
5
| | first_name=Knight           | last_name=Ni


Run the test:

Shell
 




xxxxxxxxxx
1


 
1
$ robot employee.robot


The log.html results shows us clearly that for each data record the template is executed. For each data record, the results can be reviewed.

2.2 Data Driver Library

The above works just fine when your data set is limited. But what to do when you need to verify tens, hundreds or thousands of input data? This would make your *.robot file unreadable and unmaintainable. This is where the Data Driver Library offers a solution for. The Data Driver Library allows us to use a CSV or Excel file for the input data. This way, the data is decoupled from the test script. Let’s see how this works! First, we need to install the library:

Shell
 




xxxxxxxxxx
1


1
$ pip3 install --upgrade robotframework-datadriver


Currently, the Data Driver Library has some limitations in its usage. These are not insurmountable, but it is important to know them:

  • Only the first test case will be used as a template, all other test cases will be deleted;
  • Test cases have to be defined with a Test Template at the test suite level (the template is used for all test cases whereas the Template tag we used before is only applicable for one specific test case);
  • The keyword which is used as Test Template must be defined within the same *.robot file and may not be defined in a resource file (we will explain resource files in a next blog. For now, it is enough to know that a resource file contains keywords which can be shared between several test scripts, similar to a library).

The rewritten test is available in the data_driver.robot file located in the test directory:

Python
 




xxxxxxxxxx
1
22


 
1
| *** Settings ***   |
2
| Documentation      | Test the employee Python script, data driven approach
3
| Library            | OperatingSystem
4
| Library            | DataDriver | file=data_driver.csv | dialect=unix
5
| Test Setup         | Clear Employees List
6
| Test Teardown      | Clear Employees List
7
| Test Template      | Add Employee Template
8
 
9
| *** Variables ***  |
10
| ${APPLICATION}     | python3 ../employee.py
11
 
12
| *** Test Cases ***
13
| Add Employee ${first_name} ${last_name}
14
 
15
| *** Keywords ***              |
16
| Add Employee Template         | [Documentation] | Template for verifying adding an employee
17
|                               | [Arguments]     | ${first_name}
18
|                               | ...             | ${last_name}
19
| | Add Employee                | first_name=${first_name} | last_name=${last_name}
20
| | ${output} =                 | Retrieve Employees List
21
| | Should Be Equal             | ${output}       | ['${first_name} ${last_name}']
22
...


We added the Data Driver library with the input data file data_driver.csv and the used dialect as arguments. We use unix as a dialect because we are using Ubuntu. See the website of the Data Driver library for a complete list of options which can be set. We moved the Setup and Teardown to the Test Suite level and removed it from the Add Employee Template. It is more clear to do so because also the template needs to be defined at the suite level and the result will be the same because only one test case may be added anyway. The test case itself only contains the name of the test case. Ensure that you make the name unique by using variables or another unique identifier, otherwise a warning is raised during test execution.

Shell
 




xxxxxxxxxx
1


1
[ WARN ] Multiple test cases with name 'Add Employee' executed in test suite 'Data Driver'.


The data_driver.csv contains the data we want to be tested, the first line must contain the arguments to be used for calling the template keyword:

Plain Text
 




xxxxxxxxxx
1


 
1
${first_name},${last_name}
2
John,Doe
3
Monty,Python
4
Knight,Ni


We notice after test execution that for each data record in the CSV file, a test is being created and executed:

Shell
 




xxxxxxxxxx
1
14


 
1
$ robot data_driver.robot 
2
==============================================================================
3
Data Driver :: Test the employee Python script, data driven approach 
4
==============================================================================
5
Add Employee John Doe                                                 | PASS |
6
------------------------------------------------------------------------------
7
Add Employee Monty Python                                             | PASS |
8
------------------------------------------------------------------------------
9
Add Employee Knight Ni                                                | PASS |
10
------------------------------------------------------------------------------
11
Data Driver :: Test the employee Python script, data driven approach  | PASS |
12
3 critical tests, 3 passed, 0 failed
13
3 tests total, 3 passed, 0 failed
14
==============================================================================


The log.html file also contains this result and we can verify that the SetupTeardown and the Template are invoked with the data from the CSV file.

3. Conclusion

In this post, we explored how we can write data driven tests by means of Robot Framework. We used the standard Robot Framework approach by using templates and we explored the Data Driver Library which offers some interesting functionality by decoupling the test script from the test data. This can be extremely useful when large datasets need to be tested.

Topics:
acceptance testing, python3, robot framework, tutorial

Published at DZone with permission of Gunter Rotsaert , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}