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

Depencencies to external jar files can be resolved by com.katalon.gradle-plugin. Have a look at the following topic:

No.

How do you automate setting up symlinks for you? Unless automated, it would not be a favorable solution for you. Katalon Studio will NOT help for managing symlinks at all. Then how?

Will you use Gradle to automate symlinks management? It would be possible. But Gradle is a huge accumulation of tools. You may find it difficult to learn.

The following comment by Dung Ngo may interest you:

http://forum.katalon.com/t/lounge-discussion-4-the-page-object-model-pom/18142/30

There he wrote:

In long term, when the Katalon core and API are rich and stable enough, Katalon users can leverage and build anything on top of those.

This would imply that you can build a project in IntelliJ or Eclipse backed by Maven or Gradle empowered by the published jar files of Katalon API.


I have ever tried to ā€œbuildā€ Katalon project in the external IDEs such as IntelliJ and Eclipse.

I could compile the Groovy source codes of my custom keywords and tests for them with JUnit4 and run them in Eclipse. Not in Katalon Studio, in Eclipse. Yes, I could build them.

Though my original motivation (testing custom keywords with JUnit4) was not quite successfully achieved because it was impossible to mock the Katalon runtime environment in Eclipse.

This experiment proved that I would be able to create a jar file which contains the binary class files of my custom keywords using Gradle. jar of my custom keywords!

If you could set up Gradle and write build.gradle file in your Katalon project appropriately, you can create the jar with Gradleā€™s command

$ gradle jar

and you can install the jar and pom files to the local Maven cache by the following one line:

$ gradle install

uploading the artifacts to some Maven repositories on network is also breeze by Gradle.

And at last, in another Katalon project, you want to reuse the jar. Ok, you will use com.katalon.gradle-plugin which I mentioned above.

Here I wrote write build.gradle appropriately. I would estimate it would require me to devote a few weekends.

Yes, I had already flown over your very interesting instructions and bookmarked your post for a possible later implementation. At the moment Iā€™m still using my symlink approach even for the (manually resolved) jar libraries as well, which is not ideal for them indeed. Thanks for this great hint!

You guess correctly that I havenā€™t really automated this part yet, but at the moment Iā€™m still helping myself with a simple cheat file, from which I copy the required mklink command including the respective path and execute it manually on the command line. However, I plan to use a PowerShell script for these processes in the future, which will create all needed symlinks after the first setup of a new project by Katalon Studio, depending on the respecive answers to the corresponding questions. All symlinks are created with relative paths, which ensures that they will still work when the Katalon Studio projects on this shared drive are used from an authorized client computer on the corporate network.

Almost all types of symlinks are used: Hard and soft links, to entire directories or individual files, but also junctions - depending on the artifact at hand. Usually they are softlinks, but especially my two needed versions of the .gitignore file (the one for keywords development projects and the one for real testsuite projects) require hard links, because Git has to identify them as real files to be able to recognize and manage their contents. To avoid having to create these files again and again, which would be potentially error-prone, because Katalon Studio first creates its own version of this file during the project creation process, I edit my versions in central template files, my single point of truth.

For these reasons I think the most obvious thing to do is

  1. to start my own project configuration process immediately after Katalon Studio has finished the project setup, and
  2. to use symlinks instead of copies in this process.

I am aware that my way of working and the division of labour with the teams inside and outside our company may be a little special. However, I could imagine that such an approach could also contribute to more reliable project structures and code standards in larger testing departments.

Good enough. You have automated the symlink management!

To be honest, Iā€™m not sure if youā€™re serious or mocking me. :wink: Because this cheat file is actually very helpful because I donā€™t have to change a single character in these commands for a new project. Since the relative paths always remain the same, I only have to execute these commands in the respective new project (sub)directories. I actually think thatā€™s half the way to automating these process steps.

And to pick up my earlier thought from above in this thread again ā€¦

Why not trigger both processes in one AutoHotkey script, first the project setup process by Katalon Studio itself and immediately afterwards the configuration process?

Remember, 20 July 1969 on the Moon, Neil Armstrong said

Thatā€™s one small step for a man, one giant leap for mankind.

my seriousness : kidding == 49: 51

AutoHotkey is for Windows people. How Mac and Linux people live without it?

Meanwhile I guess that Apache Ant, especially the task type Symlink, should be a good choice to do this trick platform-independently.

I stumbled across it in a different context when I was looking for a robust way to store my test results in a complex directory structure on an SFTP server in one go (look at the SCP task type for this). The actual FTP protocol is not very suitable for this requirement, because the required directories would have to be created and checked individually.

The nice thing is: There are Java libraries for Ant, with which all these useful task types, which the test automation engineer needs daily, can be used directly in Katalon Studio. :slight_smile:

However, I have to warn against two important disadvantages of symlinks in connection with the use of Git:

  1. Git canā€™t use the content of files included by soft symlink. Therefore, soft symlinks should only be used for files that are excluded from the repository by .gitignore (e.g. the /Drivers subdirectory).
  2. If another git branch is checked out and all relevant files in the project directory are exchanged in the file system, then even the connections of hard links become broken. As a result, when the original git branch is checked out again, independent copies of the previously only linked files are created in the file system.

For these reasons, I would generally only recommend the use of soft and hard links in connection with Git if it is clear from the outset that only a master branch is to be used in the development directory and no later branch checkout will be needed.

For me, neither of these aspects are real drawbacks. But I am aware that they limit the usability of this approach to very specific use cases.

But for everyone else, a look at the Apache Ant API might also be helpful, because it can do tons of other build tasks as well. If you donā€™t want your configuration templates to be symlinks, the required files could also be synchronized or updated to your project directory whenever needed.

Sorry, Iā€™m late to the party hereā€¦

AHK is pure GOLD!

I have a bunch of these setup. For example, I type ā€œTestā€ + some page object, then two dots ā€œā€¦ā€ like this:

TestMyPage..

and out pops:

import static com.my_company.utils.*

public class Test extends com.my_company.my_page {
  
  Test() {
    
    def myPageNew = new com.my_company.my_pageNew()
    
    
    writeAUTMessage '1 - my_pageNew'
    my_pageNew.navigateTo()
    
    writeAUTMessage '2 - '
    
    writeAUTMessage '3 - '
    
    
    
  }
}

try {
  new Test()
  passThisTest()
} catch(Exception e) {
  failThisTest(e.message)
}