Test data - excel binding, can we get the row number or iteration id at runtime

I am trying to input data using excel and it works fine. Now, I want to output data, and at runtime I don’t know how to get the row number or the iteration that it is executing on.

Is there a way to get the row or the iteration that it is working on.


1 Like

I suppose you mapped the excel data to the test case in a test suite, through some variables defined in the test case.

So just output the value of the variables.


I am looking for answer to the same question. Does Katalon Store the current row number that it is executing during data binding?
If yes, how can we get the value of the current row number ?

@Manjula_Siddanna, you can get the row or the iteration that is being worked on. Please refer to this guide https://docs.katalon.com/katalon-studio/tutorials/data_driven_testing.html#what-is-data-driven-testing for more details.

hello huynguyen,

I did not get answer on how to get current iteration id from the above link you shared as it leads to test case variables page which has no information on current iteration ID.
Can you re share or mention how to current iteration number.

I’m afraid this link is not helpful in getting the current active row during runtime

you can simply add one more column in your test data file having the index and map it to a tescase variable

1 Like

This url was previously titled as ‘What is data driven testing’, but now it is titled as “Test Case Variables”. The page content has been completely rewritten.

The previous content, I remember, mentioned that Katalon Studio equipped with 2 method of Data-driven testing, that is

A. Execution from test suites
B. Execute from a test case

@huynguyen, when you say “you can get the row of the iteration that is being worked on”, I think you have the method B. Execution from a test case in your mind.

However the revised content of the above url (and https://docs.katalon.com/katalon-studio/docs/run-test-case-external-data.html) now mentions the method A. Execution from the test suites only. It no longer describes the method B. Execution from a test case.

I think, it is regretful that B. Execution from a test case is now disregarded, not described in the official document at all.

Why the method “B. Execute from a test case” has been ignored out of the offical document?

I guess a recent change at v6.3.0 is related to it:

At v6.3.0, a fix for “An issue related to running a test suite with too large test data” was included. I suppose the Katalon team was so deeply devoted into the method “A. Execution from test suites” that they forgot all about the method “B. Execution from a test case”.

Thanks for the work-around. Does get the job done - in future I’ll look for a ‘cleaner’ way to do it and share it with the community. Thanks again

How about using a variable to bind Excel data at the Test Case level with optional bindings at Test Suite level (will override any variables set in Test Case level) if you had a need (eg different data)? Does this description make sense? :slight_smile:

Sorry, I do not see what you want to do, how your code will look like.

Hi kazurayam,
now that I look, I see that what I am describing is very close to a DZone article - https://dzone.com/articles/data-driven-testing-approach-with-katalon-studio. My only change is at the third step though, instead of creating variables that have a string type, I use a test data value.
The variable used in test case for example:
Name = Var_CustName
Type = Test Data Value
Default value = findTestData(“Customer_Details”).getValue(“CustName”, 1)
Part A of that article is then used to bind variables at test suite level.
I only mention this approach as the DZone article seems to give a much simpler approach than Katalon’s own documentation but I wonder if it is affected by script length issue mentioned, when test data includes many rows.

@Dan_Bown using ‘findtestdata’ will ignore any binding. it is just the programatically way of using certain testdata, instead of maping it. and yeah, this approach may not create the ‘large code issue’ since at the runtime the behaviour is different, the data is iterated during the execution phase, not generated during the compile phase