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

[Drunda_Nibel]

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

[Russ_Thomas]

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?

[kazurayam]

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?

[Russ_Thomas]

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?

[Drunda_Nibel]

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!

[kazurayam]

Drunda,

Good luck!

[Drunda_Nibel]

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…

[kazurayam]

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.

[Drunda_Nibel]

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.

[Russ_Thomas]

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.

[Drunda_Nibel]

That pleases me.

[Drunda_Nibel]

@4280-kazurayam:

Above you explained the following:

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.

I guess your jar libraries are written in Java, not Groovy, right? Since I am not an experienced Java developer and only learned a little Groovy through Katalon Studio, I would like to outsource my Custom Keywords as jar libraries to be able to reuse them flexibly in different projects. I have started a new thread on this topic:

How to create jar libraries from Custom Keywords?

Do you think you could give me some more tips on how this could be done, please? So far no one was able to contribute to this.

Many thanks + best regards!

[kazurayam]

Yes, with pleasure.

I would show you my products. There are rather complicated. so that not suitable for your reference. Just to show you that I can show you something.

Here is a “outsourced” project:
https://github.com/kazurayam/KatalonStudioBackyard

Here is a project which uses the above project’s product.
https://github.com/kazurayam/HappyMigrationSiteTest

The HappyMigratinSiteTest project peforms a series of automated test against a web-site hosted by the company I work for. The site has a lot of outgoing links like . I wanted to test these links are OK or not. The verification rule was complicated enough.
- Some links may be simply broken. The href’ed URL is no longer there. o:)
- Some links may return HTTP Status=503 Redirected to some other URL. Is it ok or no? It depends. :*
- Some links may return HTTP Status=200 OK, but its body contained a message “page is not found”. :s

Katalon Studio fell short for verifying those problematic links so that I developed a custom keyword. My keyword drives Apache Commons Http Client for itself, make a HTTP resuest, receive a HTTP response, check the response status and check the body to determine the validity of the responded contents. Developing my keyword was complicated enough. It deserved a thorough Unit-testing by Spock or JUnit. In Katalon Studio, it is impossible to run unit-testing for custom keywords. This was the very reason why I established another Eclipse project KatalonStudioBackyard apart from the Katalon project HappyMigrationSiteTest.

The project “KatalonStudioBackyard” is

• an Eclipse project
• developed in Groovy language
• Groovy codes in this project do NOT depend on the com.kms.katalon.* libraries.
• this project outputs a jar file which is supposed to be imported by other Katalon projects

The “HappyMigrationSiteTest” project imports the jar file provided by the Backyard project. In the “HappyMigrationSiteTest” project, I have a set of Keywords. The keywords depend on com.kms.katalon.* libraries. What a keyword does is

1. instanciate a Groovy classes developed by the KatalonStudioBackyard project
2. calls its methods with arguments passed by testcases to execute business logic
3. check the returned result. If any failure found, call KeywordUtil.logFailure(msg), log messageis with WebUI.comment(msg).

My keyword is very thin layer, is just a few lines of Groovy. Most of the business features are encapsulated in the classes in the KatalonStudioBackyard project.

Drunda,

Possibly you need to refactor your current Groovy codes into 2 layer:

1. com.kms.katalon.* dependent portion — entry point for Test Cases, logging, reporting etc
2. independent portion — business logic

[Drunda_Nibel]

I already suspect there’s great work in your references again. I am quite curious about it. But unfortunately both your links don’t work. Could you please check them again? Thank you very much!

[kazurayam]

Drunda,

I think that you should run through a tutorial for “Groovy programming in Eclipse”. I googled and found the following article:

• http://www.vogella.com/tutorials/Groovy/article.html

[kazurayam]

Drunda,

Here is a “outsourced” project:
https://github.com/kazurayam/KatalonStudioBackyard

Here is a project which uses the above project’s product.
https://github.com/kazurayam/HappyMigrationSiteTest

Scratch that. I remember now. These 2 repositories are private. You can not get access to them.

The latter HappyMigrationSiteTest project contains some sensitive information, so that I can not disclose it public.

The former KatalonStudioBackyard has contents that could be an open source project aiming to be useful for users of Katalon Studio, I have not worked out yet.

[kazurayam]

There is a simple reason why I had to make the project KatalonStudioBackyard independent from com.kms.katalon* packages.

Katalon team does not provide a jar file which contains com.kms.katalon.* packages to be used in other projects. No jar there. Therefore I could not make the KatalonStudioBackyard project dependent on the Katalon Studio API.

I put +1 to the following post.

Please Publish Katalon Artifacts

[kazurayam]

[Drunda_Nibel]

The latter HappyMigrationSiteTest project contains some sensitive information, so that I can not disclose it public.

The former KatalonStudioBackyard has contents that could be an
open source project aiming to be useful for other Katalon Studio users.
But I have not worked out yet.

Oh, that’s a pity, but of course it goes without saying. Needless to say, I would be very happy if you could still make the KatalonStudioBackyard available in a harmless basic version.

The HappyMigrationSiteTest project for the most part will probably be this one I already came across in another post from you, right?

Thanks also for your reference to the Groovy in Eclipse Tutorial, I’ll check it out.

But in order to estimate whether the overhead of such a backyard project to be developed in Eclipse is at all necessary for my purposes, could you please go into the following point in some more detail?

Developing my keyword was complicated enough. It deserved a thorough
Unit-testing by Spock or JUnit. In Katalon Studio, it is impossible to
run unit-testing for custom keywords. This was the very reason why I
established another Eclipse project KatalonStudioBackyard apart from the
Katalon project HappyMigrationSiteTest.

Unfortunately, I still have no immediate experience with Spock and JUnit and therefore have no precise idea of the advantages you have gained through this approach that were not possible in Katalon Studio.

Thanks a lot + best regards

[kazurayam]

Drunda,

You have developed your custom keywords without unit-testing. If you are comfortable with it, then you do not need to worry about Spock and JUnit. All you need to do is to introduce code sharing in your team.