Katalon Studio v5.8 - It's time for the all-new API testing experience
Drunda Nibel
Katalon Ambassador
05/16/2018

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

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


Upvote
Quote

Comments

  • Russ Thomas
    Katalon Evangelist
    05/16/2018
    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...
    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/16/2018
    edited May 16
    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!
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    05/17/2018
    For me it's:

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

    Take a look at this thread:

    https://forum.katalon.com/discussion/4586/how-to-pass-user-defined-parameters-from-command-line#latest

    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...


    Upvote
    Quote
  • kazurayam
    Katalon Evangelist
    05/17/2018
    edited May 17
    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.
    Upvote
    Quote
  • kazurayam
    Katalon Evangelist
    05/17/2018
    edited May 17
    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?

    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/17/2018
    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
    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/17/2018
    edited May 17
    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. :-)

    Thanks + regards
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    05/17/2018
    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 ;)
    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/17/2018
    No doubt, therefore I am very grateful for your enlightening contribution!  :) 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?
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    05/17/2018
    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...
    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/17/2018
    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!
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    05/17/2018
    I can, but not right this second.  I need to leave for about 4 or 5 hours.  I'll post an example later.
    Upvote
    Quote
  • kazurayam
    Katalon Evangelist
    05/17/2018
    edited May 18
    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.
    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/17/2018
    edited May 17
    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!
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    05/17/2018
    edited May 17
    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.

    Upvote
    Quote
  • kazurayam
    Katalon Evangelist
    05/17/2018
    edited May 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. ;
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    05/17/2018
    edited May 17
    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.
    Upvote
    Quote
  • kazurayam
    Katalon Evangelist
    05/18/2018
    Russ,
    Please understand, I don't use @Keyword.  I merely use the Keyword/Package system to build classes.  
    Now I see.
    Upvote
    Quote
  • kazurayam
    Katalon Evangelist
    05/18/2018
     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. 
    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/18/2018
    edited May 18
    Exciting discussion about this POM thing. ;) Even if the need for such a felt large overhead (apart from the advantages for variable management) is unfortunately not yet quite clear to me. Or is there much more in these page-dependent keyword files, except variable definitions?

    I now understand that one way to avoid the need for manual configuration of global variables might be to extend classes. So your hierarchy, Russ, that someone could follow is:
    Common class (is this also a Groovy keyword file or to import from jar file as external library?) => basePage class (is this also a Groovy keyword file or to import from jar file as external library?) => page class (Groovy keyword file) -> Test Case class

    Where in this hierarchy do the utility classes and the Test Listeners come into play? And how can these be integrated/imported?

    But don't these dependencies also lead to disadvantages when using the manual test case mode? I know you're not using it, Russ. But I would hate to do without it completely.

    I also find it interesting that you apparently put all the test steps into a try-catch construct. I already had this idea too, but I wasn't sure if this would be necessary at all in Katalon Studio (or only in your case because of the POM class extensions) to be able to determine the origin of a test error during the script runtime and not only from the logs received afterwards.

    Thanks you both, once again!
    And regards
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    05/18/2018
    Drunda

    Firstly, I don't necessarily think there's much disagreement between Kaz and me -- it's more likely due to my brevity (I don't have time to go into all the minor details as I would like).  But he's right about one thing (if I understood it correctly) -- Katalon does not aid me much in this kind of development.  Which brings up your question about Manual view:  The vast majority of my Test Cases contain just one line "new Test_myPage()".  But for me, this is not a big deal, I never look at Manual View, I don't add test steps or keywords using the dropdown... so for me personally, I'm losing nothing. B)

    As to your other questions:

    public class myPage extends basePage { ... }

    public class basePage extends common { ... }

    public class common { ... }
    Each of these is in its own .groovy file on disk, all belong to the com.mycompany package.


    When I write a test case:
    public class myTestCase extends myPage { ... }

    Obviously, myTestCase and myPage are merely placeholder names replaced by more specific names when implemented in a given Test Case.

    Now I have access to the methods and public vars throughout the hierarchy beginning at common through to myPage (and of course, myTestCase).

    THEY ARE ALL KEYWORD CLASSES inside com.mycompany package.  There's nowhere else to add them in Katalon (at least, nowhere else I've found).  I have NO external libs or jars.

    Regarding imports:

    Sometimes I import the myPage class(es), sometimes I target the pages via my package:

    public class myTestCase extends com.mycompany.myPage { ... }

    The other classes all contain static vars and methods.  As such, they are not in the hierarchy but they are in the package.  These are imported statically where needed:

    import static com.mycompany.utils.*
    Where "where needed" means "most test cases" :)  This file contains things such as my commenting method (which I send to the Warning log (but indented so they are not confused with genuine warnings))).  Then I can turn off all logs (damn, they're noisy), turn on Warnings and see messages super-relevant to my tests.  I only ever turn on the rest during early development of a test case (ie when I'm making tons of mistakes ;) )

    Try/Catch.  Going forward, I intend to handle all errors/exceptions myself.  Right now, my catch handler isn't doing much that Katalon couldn't do perfectly well itself.  But that might change (that's the point).

    Keep in mind, my AUT is (relatively speaking) huge.  Over a hundred pages, thousands of fields, grids and dialog boxes.  Being DRY is absolutely vital, in my  (not so humble) opinion B).  And the only way to do that, is OO development of tests and capturing "what's common" in common classes/methods.

    Hope that's made things clearer.

    Did I miss anything?
    Upvote
    Quote
  • kazurayam
    Katalon Evangelist
    05/18/2018
    edited May 19
    Russ,
    Did I miss anything?
    Yes. I wonder why you are using Katalon Studio.

    I think Katalon Studio is designed for non-programmers, not for serious Object-oriented programming. Why don't you do OO in Eclipse or IntelliJ IDEA?

    Which features of Katalon Studio let you contribute to this forum? 
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    05/21/2018
    Strange uncalled-for response.

    Why don't you do OO in Eclipse or IntelliJ IDEA?

    Because I'm new to this (check my history if you care that much).  And I have no issues using Katalon the way I prefer.  I no longer receive weird timing issues unexplained by using Katalon Manual View or its API(s).  I'm just happy to GSD, in as efficacious a manner as possible -- know what I mean? B)

    Anyway, this is seriously off-topic for this thread -- let's leave it there.

    @Drunda, how is it going? Did you manage to figure it out?
    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/22/2018
    edited May 22
    Yeah, I had a few days off, so I could not answer until now. I find your POM approach quite interesting for some more ambitious challenges. But, as already mentioned, because of the disadvantages with the Manual View I will now probably concentrate on kazurayam's proposal to define one identically named global container map variable for all my projects and then develop a project creation wizard as a PowerShell script that copies all respectively required template files to the right places.

    Thanks again and regards!
    Upvote
    Quote
  • kazurayam
    Katalon Evangelist
    05/22/2018
    Drunda,

    Good luck!
    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/22/2018
    Thank you. :) But I have to say, just the reliable renaming of a template project (including changing all file names and paths entered in configuration files) is not a trivial thing. Maybe that's why I'll switch from PowerShell to AutoHotKey to let Katalon Studio do some of the necessary process steps itself...
    Upvote
    Quote
  • kazurayam
    Katalon Evangelist
    05/23/2018
    edited May 23
    just the reliable renaming of a template project (including changing all file names and paths entered in configuration files) is not a trivial thing.
    I know. When renaming the project Katalon Studio seems to be doing a lot of messy jobs; nothing documented; dirty reverse engineering required.

    I'll switch from PowerShell to AutoHotKey to let Katalon Studio do some of the necessary process steps itself

    This sounds better. I am interested in it.

    Once you succeed, please share your experience here.

    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/23/2018
    Once you succeed, please share your experience here.
    I will. But please have a little patience, on my todo list it's pretty far behind at the moment.
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    05/24/2018
    Maybe that's why I'll switch from PowerShell to AutoHotKey

    I use AHK a lot... strangely, not with KS.  I think maybe you've sown a seed, Drunda.
    Upvote
    Quote
  • Drunda Nibel
    Katalon Ambassador
    05/24/2018
    That pleases me. :)
    Upvote
    Quote
Sign In or Register to comment.