How to save a local variable (test case variable) as a global variable so that it can be used in another test case?

I have a test script which creates a forum topic with a unique name.
Then in another test case, I would like to call that topic test case and creat a post that belong to that topic. In order to do that I need to know the topic name, but I dont have access to it.
My question is how do I save the local varible topicName into a global variable so that i can use it in my other test case. I will share the code snippet for my topic-create script.
Thanks in advance for your help.

//Call the test case for signing in as an admin
WebUI.callTestCase(findTestCase('Member/2_SignIn/4_sign-in-admin-email'), [:], FailureHandling.STOP_ON_FAILURE)

//Click on the forum menu'Member/4_Forum/forum-menu'))

//Click on the button to create a new post'Object Repository/Member/4_Forum/create-post'))

//Click on the dropdown to select a topic'Object Repository/Member/4_Forum/1_Topic/select-topic'))

//Click on the button to create a new topic'Object Repository/Member/4_Forum/create-new-topic'))

//Create a new date object to get the current date and time
Date today = new Date()

//Format the date and time to a string in the format of 'MM-dd-yyyy_HH:mm:ss'
String todaysDatetime = today.format('MM-dd-yyyy_HH:mm:ss')

//Create a unique topic name by concatenating 'Topic' with the current date and time
String topicName = 'Topic ' + todaysDatetime

//Enter the unique topic name in the text field for the topic name
WebUI.setText(findTestObject('Object Repository/Member/4_Forum/1_Topic/topic-name'), topicName)

//Upload an image for the topic header
WebUI.uploadFile(findTestObject('Member/4_Forum/1_Topic/upload-header-image'), System.getProperty('user.dir') + headerImage)

//Click on the button to edit the topic name color'Member/4_Forum/1_Topic/edit-topic-name-color'))

//Enter the color code for the topic name color
WebUI.setText(findTestObject('Member/4_Forum/1_Topic/set-topic-name-color'), nameColor)

//Submit the color code by sending the enter key
WebUI.sendKeys(findTestObject('Member/4_Forum/1_Topic/set-topic-name-color'), Keys.chord(Keys.ENTER))

I have tried using GlobalVariable.putAt("topicName", topicName) but no lucj

@kazurayam If you have any insight on this.

This code will never work.

I assume, you defined a GlobalVariable named “TOPIC_NAME” as String type in the “default” Execution Profile. Then you want to write:

String topicName = "foo"
GlobalVariable.TOPIC_NAME = topicName

Why? I will explain it. See the next post.


Please be aware that you can define a GlobalVarible of type java.util.Map. A GlobalVariable of type Map, which is a collection of anonimous key=value pair, is quite expressive and useful.

In the project directory, you would find a file


Open that file with your favorite text editor (not by Katalon Studio). You will find the file something like:

import ...

public class GlobalVariable {
    public Object TOPIC_NAME;

This source file is generated by Katalon Studio based on the definition of an Execution Profile you selected just before you run your test.

This Groovy file defines a class GlobalVariable, which contains a property named TOPIC_NAME of type java.lang.Object.

So you can set any value to it by a single line that I showed you above.

Should we really be using global variables like this?

Also, is that second test case happening some time later than the first test case finishes? If not, you could just pass the variable straight into that second test case.

I tend to avoid ‘call test case’ if not really. needed.
E. g supposed the data has to be retrieved only once, but multiple other testcases has to reuse it.
With ‘passing the variable directly’ it means the data retriever has to run each time if it is called by the consumers, or the data retriever has to call each other.

this add an unecesary factor of complexity to the project design

By using a global variable will be easiest, but the darkside is, such are scoped only to a test suite execution

In this case, it seems to be exactly what’s needed.

If a test case depends on several units of work, you call those several units. Period.

I’m sorry, but this is a copout. Good, idiomatic, design should not be sacrificed for meager “performance gains”. We shouldn’t pollute global variable namespace over it.

IMHO, GlobalVariables should be used for configuration data. If the global variable is to be used for some test case that gets started by the user some time later, it is probably better to write it to some Excel file (or something similar) and have the test case read from that file…

… but that’s not what it sounds like is going on here…

well, looks like we have different visions on what katalon was and what katalon can be.
to my defence, i am no longer a current user.
simply because i found my path.
i was an active user since… dunno, 5.something.
but not anymore

i like your proposals, but looks like you are not aware of how katalon actually works and how is developped.

so you are proposing sane approaches most of the time.
and it is fine, and i will support you.
but some time, you tend to ignore what the actual use case is, in the current context.

just saying…

agreed. for more complex solutions there are better proposals.
feel free to search the forum and came with improvements.
‘call test case’ is an abominating feature and i will never use such garbage approach
in my vision, each and every test case should be mutual independent.

about sharing data across testcases, we can debate

who are we?
are you a katalon developer or user?
speaking for myself, as an user, i will abuse it on purpose, just to see what hapens.
simply because is there.
i was a tester some time ago, cannot forget those good old times

Now, on the sharing data across testcases …
Everything depends on how large is the data to be passed from one testcase to another.
If the data is too complex, few solutions came into my mind rigtht now:

  • write the data into a file, like @mwarren04011990 suggested (plain text, csv, excel, whatever is more appropiate)
  • use a custom class (I think @Russ_Thomas have somewhere an example of this, I did’nt manage to find it right now). Anyway, this will not diverge too much from using GlobalVariables, which in the end are just properties of a class instance, instantiated by parsing the xml files corresponding to the curent exectution profile (top of the default one)
  • use sqlite - here @kazurayam made some research:
    Issue while writing on excel file with parallel execution - #6 by kazurayam
  • use a nosql db if it is more appropiate, if you have one available (someone brave have to write an example)

… or whatever else.

But please, avoid using ‘call test case’ unless the use case is very-very simple.

@bionel As you know, I tend to avoid this whole debate, mostly because test code does not need to have the same kind of rules you might apply to production, user-targeted code.

To reference data, I’ve used:

  1. external files
  2. a single external file (tied to the Kat project) that populates my global variables
  3. And, as you pointed out, data classes.

From a test ops perspective, #3 is the least troublesome. # 1 and 2 can cause issues when you screw up the CI. Not that that’s difficult to fix, but it wastes time while you’re investigating and scratching your head – never get that problem with #3.

good point!

“probably better”? What’s your metric?

Any simple text file is “probably better” than Excel, in my view. And any form of class-based, in-project data is better again, for the reasons I mentioned. I don’t need and cannot justify the extra cognitive load involved when it gives me back nothing in return – except test ops headaches once in a while.

The other thing I do (which I believe no one else does) is store Test Case metadata (JSON format) in the Test Case properties (no external files required, the data is printed along with my reports).

My philosophy, if it isn’t obvious already, is to reduce movable parts.

Few more thoughts on this.
I am not sure what the concerns are. I suppose here, @mwarren04011990 won’t like the execution profiles to be ‘polluted’ with unneeded variables.
Few solutions here.
Understanding how GlobalVariable works, we can put ‘irelevant’ variables in the default profile. There is no need to have a real default value, just to exist and be declared with the right type.
Relevant configuration data for the environment subject to test (staging, production etc) can be stored in the associated execution profile.
So, we segregate the configuration data from the shared data variables.

If this is also disliked, the GlobalVariables for data-sharing can be added ‘on-the-fly’ so will never be shown in the UI (Katalon never writes back such during/after the execution, like Postman do).
We simply extend the funtionality of GlobalVariables class to use it also as a container for temporary data.
An example of how this can be achieved is here:

I consider myself a test dev. I worked as software developer, but now I am freelance web automation tester.

I bring over with me principles of good software/code design, some of which have sparked my solutions/blog posts/design decisions on here.

I knew how to do web auto testing back in the days of that software developer job, but was brought on mainly as…developer!

thought so, despite my question was about a slightly different subject.
well, keep up with exploring this toy, chances are you may discover new programing approaches.
or not…

Hi @yvan.militisi, :wave:

Just checking in to see whether you were able to find the answer to your question or not. If yes, then it would be great if you could mark said answer as a solution :white_check_mark: to show your appreciation to the person who posted said answer. Thanks! :smile: