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
//Click on the button to create a new post
//Click on the dropdown to select a topic
//Click on the button to create a 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
//Enter the color code for the topic name color
//Submit the color code by sending the enter key
I have tried using GlobalVariable.putAt("topicName", topicName) but no lucj
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.
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)
@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:
a single external file (tied to the Kat project) that populates my global variables
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.
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:
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 to show your appreciation to the person who posted said answer. Thanks!