DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Migration From One Testing Framework to Another
  • Design Patterns for Scalable Test Automation Frameworks
  • Architecture Patterns : Data-Driven Testing
  • Cypress API Testing: A Detailed Guide

Trending

  • Build Your First AI Model in Python: A Beginner's Guide (1 of 3)
  • Unlocking AI Coding Assistants: Generate Unit Tests
  • MySQL to PostgreSQL Database Migration: A Practical Case Study
  • Understanding and Mitigating IP Spoofing Attacks
  1. DZone
  2. Coding
  3. Frameworks
  4. How to Write Data Driven Tests With Robot Framework

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!

By 
Gunter Rotsaert user avatar
Gunter Rotsaert
DZone Core CORE ·
Jun. 09, 20 · Tutorial
Likes (5)
Comment
Save
Tweet
Share
19.5K Views

Join the DZone community and get the full member experience.

Join For Free

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 Setup, Teardown 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.

Testing Data file Robot Framework Framework

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

Opinions expressed by DZone contributors are their own.

Related

  • Migration From One Testing Framework to Another
  • Design Patterns for Scalable Test Automation Frameworks
  • Architecture Patterns : Data-Driven Testing
  • Cypress API Testing: A Detailed Guide

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!