Pass common test data in entire Test Suite

In my project, some of the test cases in a test suite work on same test data values. Initially, I was passing the Test data in data binding dialog for each test case of a test suite individually. But due to drastic change in my test data, I realised that I now have to goto data binding for each test case and fix the test data value.

Is there a possible way, where I don’t have to change test data value for each test case individually? I would like a solution(if possible) where I have to change the test data only at one place and it should work for that entire test suite.

Alongside the standard offerings (DDT for CSV, Excel, DB, etc) you can provide your own mechanisms to handle data.

  1. External data files (XML, JSON) and read the data yourself.

  2. Internal data classes (Groovy classes).

I never use DDT, sometimes use #1, mostly use #2 - far less moving parts, self-contained and transportable across systems.

Hi @Russ_Thomas,

Thank you for the quick response. If possible, could you guide me how can I use Internal data classes, maybe any github project I can refer to or any other resource?


You haven’t showed your own project much, so here I assume your project looks like the sample described by the following article.

This article tells that Data Driven Testing in Katalon Studio offers 2 ways:

  • A. Execution From test Suites
  • B. Execute From a Test Case

Here I assume you have followed the way “A. Execution From test Suites”, not “B. Execute From a Test Case”.

Now, you wrote:

This is not clear enough to me. I would restate it as follows.

When you created a Test Case, you were requested to edit the “Variables” tab of the test case where you added 2 variables “demo_usn” and “demo_pwd”.

Let me assume you wanted to create a lot more Test Cases “TC1”, “TC2” and “TC3”, and all of these additional Test Case scripts required the data supplied by the Data Binding mechanism. Then you had to add variables “demo_usr” and “demo_pwd” to all of New Test Case, TC1, TC2 and TC3.

Now let me assume you want to change the external Excel file and add a new column named “demo_foo”. Then you need to change TC1, TC2 and TC3.

  • operation 1. You have to open each Test Cases definition; navigate to the “Variable” tab; add a new variable “demo_foo”.

This is just half of the job involved.

  • operation2. You need to open the definition of your Test Suite; click “Show Data Binding” button to make the Data Binding settings visible; choose a test case and associate “demo_foo” variable to the external data; repeat this operation for all of your test cases TC1, TC2, TC3.


I guess, you find the above operations 1. and 2. are cumbersome. You want to find way how to avoid them. You would change your Excel sheet, and you do not want to do any more.

I understand your initial post like this. Am I right?

The article described 2 ways.

  • A. Execution From test Suites
  • B. Execute From a Test Case

If you take the “A”, your test case will have the following line:

WebUI.setText(findTestObject('Page_Login/txt_UserName'), demo_usn)

On the other hand, if you take the “B”, your test case will have the following line:

WebUI.setText(findTestObject('Page_Login/txt_UserName'), data.internallyGetValue("demo_usn", index))

Do you understand the difference between these 2 lines?

data.internallyGetValue("demo_usn", index) in the script “B” is replaced to a Groovy variable (demo_usr) in the script “A”. Behind the scene in “A”, Katalon Studio retrieves the data from external Excel sheet and inject it into the associated Test Case Variable; this automaton is what “Data Binding” means. This approach requires you to define variable names in Test Case’s “Variables” tab. @shivam1, you want to avoid this setting work, don’t you?

In “B”, you do not have to add Test Case Variables “demo_usr” and “demo_pwd”. The script of B refers to the data by String literals("demo_usr") not by a Groovy variable (demo_usr). Therefore you can avoid the operation 1 if you follow the approach “B”.

However, in both of “A” and “B”, if you want to make your test refer to the newly added “demo_foo” data, you need to change your Test Case script anyway.

No, there isn’t.

If you add a new data column in your Excel sheet and leave your test cases unchanged, then simply the new data will be ignored and unused. If you want your test cases to refer to the new data, you have to change your test cases anyway; this applies to both of approach “A” and “B”.

Russ_Thomas suggested another way of life without DDT, and I believe his comment is valid. But you should be aware, if you are to follow his suggestion, you have to rewrite your existing test cases totally in Script mode. His way assumes you are a good Java/Groovy programmer. But you haven’t displayed your programming capability yet. So…

I think that this might be the shortest path for you.

“B. Execute From a Test Case” in might be informative for you.

Hi @kazurayam,

Thanks for the great insight.
What are your thoughts on implementing BDD framework? Wouldn’t that solve the problem of managing test data?


As far as I see, BDD frameworks are all about how to express assertion statements and how to report failures in our spoken languages. E.g, English, Chinese, Vietnamese for you; or Japanese for me. It’s also called Gherkin Language. Yes, language matters in certain respects; but it is irrelevant to the efforts required to manage test fixtures.

Cucumber API provides a class named Data Table that wraps a 2D array and provides various accessor methods. But I do not think we need DataTable in Cucumber tests in Katalon Studio; I think that com.kms.katalon.core.testdata.TestData would be a better choice if you perform Cucumber tests in Katalon Studio…

For your informartion, see

Hi @shivam1Please let me know if you have figured a solution for this .I need the same thing to be implemented in my project

Did u get a solution for this?
If yes please provide the example script for the same

As I wrote in May '21, see

I checked the “Test Cases/bdd/runCuraLoginFeatures” in it. It worked as expected. I have no more to add.