What are some ways to simplify a test case variable state specification?

What are you asking?

This is meant as a follow-up to this question not being answered.


Before we jump into the problem description, I should point out that, when we’re talking about “practice profiles”, we are NOT referring to the Execution Profiles. We are referring to some business data type.


In the Global Variables, we are still forced to go to Script mode, just to change the state of a variable of some business type, for example with practiceProfile.

We have this method on our singleton class PracticeProfileHandler called getPracticeProfile(), which accepts the practice name and returns a practice profile object from the data store that has that practice name.

Right now, using it looks like this:

We have to spell out the fully-qualified package name for it ! YIKES.jpg

Another part of the problem: Test cases

Also, with very few exceptions, we have Test Cases with a practiceProfile variable that, defaults to GlobalVariables.practiceProfile.

What changing the test case variable state looks like

Suppose we want to add some family member leads to a practice, and that was the only thing we wanted to do. Run no other test cases. Just that one to create some family members.

We realize that the default practice profile state may be different from what we want to use. So, we go to set it in the Variables tab…

For some odd reason, we can’t point to PracticeProfileHander.GetInstance().getPracticeProfile() in the variables tab… I can’t retrieve any methods on that PracticeProfileHandler, nevermind the static one that we need to get first…

…and forget chaining methods!

If we wanted to not use that default state (for example, if we wanted to add member leads to just that is in the GlobalVariables.practiceProfile, we have to go into Variables (Script mode) tab and do the same thing we did for that global variable… :nauseated_face:

What does your PracticeProfileHandler look like?

Like this:

public class PracticeProfileHandler extends BaseRecordHandler<PracticeProfile> {

	private static PracticeProfileHandler _instance;

	private PracticeURLHandler childPracticeURLHandler;
	private OrganizationNameHandler childOrgNameHandler;

	public static PracticeProfileHandler GetInstance() {
		if (this._instance == null) {
			this._instance = new PracticeProfileHandler();
		return this._instance;

	protected PracticeProfileHandler() {
		super("./Practice Profiles.xlsx");

	public PracticeProfile getPracticeProfile(String practiceName) {
		return new PracticeProfile(this.childOrgNameHandler.getOrganizationName(practiceName),

	//... more business logic...

What are you wanting to about it?

I have a few ideas, that wouldn’t involve shotgun surgery to the literal hundreds of test cases that take a practiceProfile variable:

  • if there is some way to have some wrapper method in package internal or any other package that the test case XML recognize without having to spell it out, that will call my PracticeProfileHandler.GetInstance().getPracticeProfile(profileName), where profileName is the name of the practice profile we want to use
  • manipulate the TestCaseContext inside the test listener @BeforeTestCase method, to, if it sees a practiceProfile equal to some string, fetch the practice profile into that variable, by that name. This would allow the user to simply pass in the practice name.

Both of these methods feel a bit…hacky… @kazurayam , Katalon community, any ideas on how I can solve this once and for all without shotgun surgery?

NOTE: question has been updated for more clarity

I don’t understand your posts.

What does your code fragment PracticeProfileHandler.GetInstance().getPracticeProfile(profileName)
is meant to do? This is the first point you should explain to others. But you didn’t. So all your description just puzzles others.

It is supposed to fetch a practice profile from the data store by some profileName

I guess, you have several Excecution Profiles defined and you want to load one or more of them programatically. Katalon Studio does not provide such API to load Execution Profiles programatically.

I have ever addressed it and I have got my own solution. See the following post:

  1. I want a capability that my test script can choose which Profiles to load programmatically runtime .

I’m sorry for the confusion.

The practice profiles are not to be confused with Execution Profiles.

They are merely objects that have the following info:

  • practice name
  • practice URL
  • organization name

They are business data, that drive things like test case and test suite setup, after more global setup steps (i.e. driver init, navigate and log into AUT) have completed, but right before the actual test case steps happen.
They are stored in a data store, that is managed by PracticeProfileHandler class…

For example, when we call the test case to create a practice, a PracticeProfile is created after successful practice creation, and passed into the child test cases right there…

…after PracticeProfileHandler…handles… it

I’m not sure I followed any of what you said… the way you’ve presented your issue is so unclear and convoluted I simply gave up. But, here’s a shot in the dark…

I pull in an external file (whatever.json) of properties and assign them to a Groovy global object. This happens during @BeforeTestCase. Some of the properties are copied to the GlobalVariables object, where it makes sense, but the rest live in the groovy object and stay there.

Why do it this way?

It’s easy to produce the json file from other systems/processes. The code in @BeforeTestCase “blindly” copies the data and assigns it where it’s needed.

No messing with internal, no tinkering with the GlobalVairables XML…

@kazurayam @Russ_Thomas

I updated the question for more clarity. I hope it is clearer now…

Sorry, I don’t undestand this.

A little.

I’m not surprised. In the KS environment, unless I’m mistaken, your codebase is not in scope.

With your programming skills, I wonder why you’re messing around with the variables tab. You can clearly see it’s meant more to aid non-developers than it is meant to be the all-encompassing vars management utility for test cases.

Stop trying to shoehorn your “idea” into a UI intended for Mickey Mouse settings and instead, make an overwritable external json file stuffed with the data you need. Load it in @Before (test case or suite).