Differences Between Keywords and Include in Katalon?

Hello everyone,

I’m exploring how to organize source code in Katalon Studio and have some questions about the differentiation between the Keywords and Include folders.

  1. What is the difference between these two folders? I want to understand how each folder should be used most effectively, especially when handling methods and classes.
  2. What folder structure are you using? Can you share how you organize your source code between Keywords and Include, as well as the benefits you have gained from that division?

I look forward to your insights and sharing. Thank you!

1 Like

Katalon originators designed the “Keywords” folder to be a place where you locate the Groovy source of your Custom Keywords.

They designed the “Include/scripts/groovy” folder to be a place where you locate the source of your Step definitions for Cucumber. Katalon Studio’s GUI is designed so that users would create Cucumber codes in the Include folder, not in the Keywords folder.

So, these 2 folders were originated with different intentions of the Katalon developers how users should use these folders.


However, you can jump over the originators’ intentions. You can add any types of custom Groovy classes in both folders.

Do you want to create your own arbitrary Groovy class in a katalon project? Do you ask us where you should add it: in the “Keywords” folder or “Include/scripts/groovy” folder?

With this respect, there is no difference between the “Keywords” folder and the “Include/scripts/groovy”. A proof is here. In every Katalon project, you will find a file <projectDir>/classpath. It will look something like:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
	<classpathentry kind="src" output="bin/keyword" path="Keywords"/>
	<classpathentry kind="src" output="bin/listener" path="Test Listeners"/>
	<classpathentry kind="src" output="bin/lib" path="Libs"/>
	<classpathentry kind="src" output="bin/groovy" path="Include/scripts/groovy"/>
        ...

As you can see, both of the “Keywords” folder and the “Include/scripts/groovy” folder are included in the classpath; classes in the both folders are equally available to all your custom code. In this sense, these 2 folders have no difference.

3 Likes

Just to give you an idea, please refer to my years-old post:

In this “junit4ks” project, I used the Keyoword folder and the Include/scripts/groovy folder for my own intention.

My “junit4ks” project assumes a case that

  1. you want to develop some “Custom Keyword” of your own in the “Keywords” folder
  2. you want to perform “unit testing” for your Groovy classes located in the “Keywords” folder
  3. so you want to develop junit4-based test classes in the “Include/scripts/groovy” folder
  4. finally you want to develop “test runner” scripts in the “Test Cases” folder. The “test runner” script runs JUnit4 to execute the class in the “Include/scripts/groovy” which indirectly calls the Groovy classes in the “Keywords” folder.

If you are familiar with Maven or Gradle, you already know, the De facto Java/Groovy project folder structure is as follows:

project
    |
    +---src
        |
        +---main
        |    |
        |    +---groovy
        |        |
        |        +---mypackage....
        |
        +---test
        |    |
        |    +---groovy
        |        |
        |        +---mypackage....

For me,

  • Katalon’s “Keywords” folder is something like the “src/main/groovy” folder in a Gradle project.
  • Katalon’s “Include/scripts/groovy” folder is something like the “src/test/groovy” folder in a Gradle project.

My idea was simple: I wanted to locate the application classes in a folder, and the unit-test classes in another folder. I wanted to separate them. However Katalon Studio does not allow users to configure the classpath; it is given as is defined by the classpath file. So I assigned a role of “src/main” to the “Keywords” folder; a role of “src/test” to the “Include/scripts/groovy” folder. Regrettably enough, I must say, this idea is not intuitive; is difficult to perceive.

Katalon is not designed with the unit-testing for your own custom classes in mind. I would not recommend you to follow the way of my “junit4ks”.

1 Like

@le.duc.anh

You might find the following post of mine interesting:

1 Like

Hi @kazurayam
Thank you so much for the detailed information you shared. It was incredibly helpful :handshake:

2 Likes