How to define Global Variables within Scripts, i.e. "on the fly"?


#1

Hi,

I wonder if there is a way to bypass the manual profile configuration to define global variables. Because I would like to reuse my general keyword scripts directly in every project, without first having to make presettings in several Katalon Studio menus.

Or are there alternative, more reasonable approaches to such workflow challenges?

Thanks + regards


#2

Hi Drunda

There probably is a way to do it directly in code, but it isn’t as straightforward as a simple assignment statement.

The global vars are stored in a file, GlobalVariables.glbl in your project folder on disk. What you could do, is prepare the file in advance, copy it to the relevant project folder, then run your suite.

A bit messy though…


#3

Hi Russ,

I have found now /Libs/internal/GlobalVariable.groovy, which seems to be the file you mean, do you?

But you’re right: copying or synchronizing these and all other related settings files every time a new project is to be created doesn’t seem to be more useful than filling out the intended dialogs. And it will even hardly be less error-prone, I think.

Then, maybe, the most obvious way out could be Git? But I have no experience with Git and especially not with the Git integration within Katalon Studio. Will I be able to take over different parts from other projects as needed with every new project? But maybe I should start a new topic for that question?

Thanks + regards!


#4

For me it’s:

C:\Users\<username>\Katalon Studio\<projectname>\GlobalVariables.glbl

Take a look at this thread:

I guess it’s possible the file has moved in KS 5.4.x (I’m still using 5.3.1). Double check the root of your project.

Here’s my loose algorithm:

1 - In one project, create all the globals with basic values or empty strings “”

2 - Archive a copy of that file somewhere

3 - Make copies with specific values for target systems/environments

4 - In my suite runner, add a line to copy the correct batch file into place before kicking of the suite with the KS command line
On my system, I copy the files into place using a batch file – doesn’t involve Git at this point.

I may have forgotten some of the details, but you get the idea…


#5

Because I would like to reuse my general keyword scripts directly in every project, without first having to make presettings in several Katalon Studio menus.

I have ever had a similar requirement: want to reuse a set of custom keywords in multiple projects. I developed my own solution using the External Libraries feature of Katalon Studio.

I would explain my solution by an example. In my Katalon project I have a Keyword: verifyAccessiblity(String urlString)

package com.happymigration
import com.kazurayam.ksbackyard.AbstractHttpURLVerifier
import com.kazurayam.ksbackyard.DefaultVerifiableHttpURLConnection
import com.kazurayam.ksbackyard.HttpURLVerifier
import com.kazurayam.ksbackyard.VerifiableHttpURLConnection
import com.kms.katalon.core.annotation.Keyword
import com.kms.katalon.core.util.KeywordUtil
class HMHttpURLVerifier extends AbstractHttpURLVerifier implements HttpURLVerifier {
  @Override
  @Keyword
  public boolean verifyAccessibility(String urlString) {
    StringBuilder sb = new StringBuilder()
    Optional<VerifiableHttpURLConnection> opt = this.connect(urlString, sb);
    VerifiableHttpURLConnection conn = opt.orElse(DefaultVerifiableHttpURLConnection.EMPTY);
    boolean result = conn.isAccessible();
    if (!result) {
      KeywordUtil.markFailed(sb.toString())
    } else {
      KeywordUtil.markPassed(sb.toString())
    }
    return result
  }
  @Override
  protected VerifiableHttpURLConnection createVerifiableHttpURLConnection(HttpURLConnection conn, StringBuilder sb) {
    return new HMVerifiableHttpURLConnection(conn, sb)
  }
}

You should not too much worry about 4 classes of com.kazurayam.ksbackyard package. These are my custom classes.

Important point is that I developped the com.kazurayam.ksbackyard classes outside Katalon Studio.

I made a project in Eclipse where I developed these classes. I made a jar file which contains the com.kazurayam.ksbackyard package. Then I added the jar into my Katalon projects using External Libraries feature. Once the jar is added, all the com.kazurayam.ksbackyard classes become available to my custom keywords.

My custom keyword implementation is a thin layer which has just a few lines of codes. On the other hands my classes in the com.kazurayam.ksbackyard are large and complexed.

I can reuse the jar of com.kazurayam.ksbackyard classes in as many Katalon Projects as I want, because the jar is created outside a Katalon Studio.

Another reason why I developed my classes outside Katalon Studio is that they are large and complicated enough so that they deserved thorough unit testing with testing frameworks such as JUnit and Spock.

I found that I can not test my classes for custom keywords using JUnit in Katalon Studio. So I decided to design 2 layers of my classes:

  1. @keyword classes which are tightly coupled with Katalon Studio API
  2. classes which are independent from Katalon Studio API, and will be called by the classes of (1)

I develop the 1) classes in Katalon Studio — just a few lines. Yes I need to repeat presetting keywords in the Katalon Studio’s menu, but it is not so difficult.

I develop the 2) classes outside Katalon Studio — bunch of lines thoroughly tested with JUnit. These classes are reused in many Katalon projects.

This design (keywords implemented with 2 layers) worked for me.

To be honest, my way was hard to achieve. Not easy at all. It required a few weeks of programming efforts. My implementation is still immature. I have found many outstanding design issues in order to make this design useful for others. But I suppose it would be better than manipulating GlobalVariables.glbl file runtime.


#6

Well, my comment above seems to be irrelevant.

Drunda,

I wonder if there is a way to bypass the manual profile configuration to define global variables. Because I would like to reuse my general keyword scripts directly in every project, without first having to make presettings in several Katalon Studio menus.

As far as I understand, you want to reuse your keyword scripts in multiple projects. Then you talk about manipulating Global Variables. I do not see how manipulating Global Variables in a project can contribute to effective keyword reuse in multiple projects. Would you please explain a bit more?


#7

Hi Russ,

For me it’s:

C:\Users\<username>\Katalon Studio\<projectname>\GlobalVariables.glbl[…]
I guess it’s possible the file has moved in KS 5.4.x (I’m still using 5.3.1). Double check the root of your project.

Yes, this seems to be the case, obviously in connection with the conversion of global variables to profiles.

Here’s my loose algorithm:

[…]
4
- In my suite runner, add a line to copy the correct batch file into
place before kicking of the suite with the KS command line
On my system, I copy the files into place using a batch file – doesn’t involve Git at this point.

By “suite runner” you probably mean a batch or shell script at the end of which you have included the command line required to start Katalon Studio together with the respective project, right? And before in this script you copy the required version of the GlobalVariables.glbl file, also correct?

Since I am currently planning to run my test projects using PowerShell scripts anyway, I have to say that I don’t really dislike your approach, as far as I understand it correctly.

However, when reading the posts still referenced by kazurayam below, I also noticed that the Katalon team may (hopefully) soon provide a way to insert dynamic parameter values via the command line. Based on my initial question, this of course also assumes somehow that the necessity of having previously defined the required parameters in the respective project as global variables would have to be dispensed with. However, maybe I should wait for that development to be able to rely on a future-proof workflow, which can’t soon be ruined again by changes to the Katalon software (like the current conversion of the GlobalVariables technology).

Many thanks + regards


#8

Hi kazurayam,

many thanks again for your great efforts in
describing your approach! I would not say that your contribution is irrelevant, in fact I have mixed some things (Global Variables and Keywords) in my question and in fact I had something like that in mind. Because actually I want to reuse both my Keyword scripts and my Global Variables. And it would be best to integrate my external libraries automatically too when creating a new project. And all this preferably by script, if necessary also outside of Katalon Studio using PowerShell or something similar.

But as
you already suspect, your approach looks very complicated to me. I would like to
rely as much as possible on technologies that can be developed and
maintained either by the Katalon team or by myself. Since I’m not a Java
professional (I’ve only worked with script languages so far), your
approach, which I highly appreciate, seems to be too
complicated for my purposes. I am sure it will be helpful food for thought for some readers looking for something similar. But one of the reasons I came to Katalon Studio
was to avoid dealing directly with a pure development environment like
Eclipse and frameworks like JUnit or TestNG. Maybe in the course of my
young testing career I will be able to do that at some point, but for the time being I think it is a little too big for me. :slight_smile:

Thanks + regards


#9

By “suite runner” you probably mean a batch or shell script at the end
of which you have included the command line required to start Katalon
Studio together with the respective project, right? And before in this
script you copy the required version of the GlobalVariables.glbl file,
also correct?

Yep.

However, maybe I should wait for that development to be able to rely on a
future-proof workflow, which can’t soon be ruined again by changes to
the Katalon software (like the current conversion of the GlobalVariables
technology).

Possibly. But you asked your question “today” – I can’t (or should not) answer a question based on non-existent things. Indeed, things which may never exist :wink:


#10

No doubt, therefore I am very grateful for your enlightening contribution! :slight_smile: But I’m just actually a little torn right now because of this floating situation.

I just came across the possibility of simply defining public variables in my scripts. Shouldn’t I be able to use them just like global variables, only that I can actually define them myself in my test case and keyword scripts? Then I would only need to provide a project-suite-dependent Excel or CSV file with a fixed defined project storage path and all required variable values in it and would perhaps be a little more flexible for inserting the respectively required configuration. What do you think about this?


#11

What do you think about this?

I do it myself, so as to my opinion… B)

But are you sure public vars answer all your problems with globals?

In my code, my test cases are (99% of the time) single statements when viewed in Manual View. Each TC defines its own class whose constructor contains the test steps. The class itself extends a baseClass which (further up the hierarchy) defines the public vars you’re referring to. It works for me, so far…


#12

Can you please give me a small example how such a test case looks like to you (in script mode)? That would be great, thanks!


#13

I can, but not right this second. I need to leave for about 4 or 5 hours. I’ll post an example later.


#14

How about this idea?

(1) You can define a GlobalVariable of type java.util.Map. You can name it whatever. Let me name it ‘myVars’ here.

You need to create the ‘myVars’ as GlobalVariable manually before running the test. But it is a single step. Easy, isn’t it?

(2) In your TestListener in the method annotated with @BeforeTestSuite, your script add name-value pairs as many as you want into the ‘myVars’ as follows:

GlobalVariable.myVars['foo'] = 'bar'

(3) Your TestCase script will refer to the values contained in the ‘myVars’ as follows:

def value = GlobalVariable.myVars['foo']
WebUI.comment("GlobalVariable.myVars['foo']=${value}")

(4) Your test case script can add/modify/delete entries in the ‘myVars’ as you like.

The ‘myVars’ can be regarded as a flexible container of public variables visible and sustained in a test suite scope.

One shortage of ‘myVars’ approach would be, you can not see the content (=a list of name-value pairs) of the dynamic ‘myVars’ at all in the Katalon Studio GUI. All you can do is to write a code which prints the myVars contents in the log. Poor man’s Porche.


#15

Hi kazurayam,

indeed, that sounds like a very good idea to me! Why hasn’t anyone thought of it yet, or has it?

The fact that this “container” can be the basis for any varying and extensive content also makes this approach very interesting for another idea that is gradually maturing in me: A PowerShell script with which I can create a completely preconfigured standard project for the specific needs and workflows in my company from any combination of template files. Because in this case I would (hopefully) hardly have to edit any file contents “on the fly”, but perhaps only need to have the necessary Groovy package files and configuration data sources copied to the right places. Do you think this could work?

But I want to take a closer look at Russ’s public variables approach first …

Many thanks again + regards!


#16

Drunda

I do exactly the same thing with maps that Kaz is doing. Some of my vars persist across testing sessions (those are the vars I populate via file copy) but many more are stored in public vars in my base classes. Most of my startup conditions are handled by decisions made in TestListeners (hooks).

I think you want to spend time thinking about how you intend to use KS going forward. If you’re comfortable with script (classes and methods etc) then read on.

I use a POM (page object model). Each page in my app gets its own dedicated class (.groovy file, a keyword class in KS-speak).

Each page class extends (inherits from) a basePage class (which itself extends a Common class). Plus I have a couple utility classes which contain a bunch of static utility methods.

com.mycompany.utils // utilities
com.mycompany.js // javascript
com.mycompany.jq // jQuery

So, imagine I have a web page called invoicing. For that page I’d create a keyword class:

public class invoicing extends basePage {…}

And for each test case I’d create:

import static com.mycompany.utils.*

public class Test_invoicing extends com.mycompany.invoicing {
  Test_invoicing() {
    try {

      // list of test steps (calling test methods)

    } catch(Exception e) {
      mycomment 'Exception: ' + e.message
      throw e
    }
  }
}

new Test()

Any public variable defined anywhere in the class hierarchy from Test_invoicing all the way back to common, is visible and usable inside the Test_invoicing constructor. Plus, any public static defined in com.mycompany.utils is available, too.

I also define classes for dialogs that popup (along with a baseDialog class behind it). And the same for grid controls.

I hope that made some sense to you.


#17

Russ,

I use a POM (page object model). Each page in my app gets its own dedicated class (.groovy file, a keyword class in KS-speak).

I could hardly imagine a keyword can represent a POM. Now I understand why you talked about GEB at https://forum.katalon.com/discussion/5690/has-anyone-used-geb-in-katalon-studio.


#18

Kaz

I could hardly imagine a keyword can represent a POM

Please understand, I don’t use @Keyword. I merely use the Keyword/Package system to build classes. I’d much prefer to use something else to get my groovy classes incorporated into my test environment, but I don’t know enough about how Katalon pulls together its Java core (yet). Maybe there is a better way? The last time I used Java was (I think) 1993… it was called Oak if I recall correctly. And then it appeared in Netscape as Java… fun days.

But yes… I think the POM approach is far more suited to an old coder like me B). The Manual view I guess suits non-programmers but it’s not DRY enough for me.

Re GEB. I admit I’ve forgotten what it was I liked about it. When I posted, I’d read a couple articles somewhere and was intrigued to find out more (and as the post says, I tried it and gave up due to errors I couldn’t figure out). But since then, I’ve done nothing with it.


#19

Russ,

Please understand, I don’t use @Keyword. I merely use the Keyword/Package system to build classes.

Now I see.


#20

I think the POM approach is far more suited to an old coder like me

I would disagree with this.

I can imagine an IDE for web UI testing, which is built on top of the POM approach, and which is designed for non-programmers. Thing is, Katalon Studio is not that one. It would deserve another project.