In professional test automation, we strictly follow the DRY principle (Don’t Repeat Yourself). If a piece of logic—like logging in—is used more than once, it should live in exactly one place. This way, if the developers change an element ID tomorrow, you fix it in one single spot, and all 30+ tests instantly adapt.
In Katalon Studio, you have two excellent built-in ways to handle this:
-
Call Test Case (Built-in Keyword): Perfect for standard workflow reuse.
-
Custom Keywords (Groovy/Java): Ideal if you want a clean, programmatic function you can call seamlessly across scripts.
The Explanation: What went wrong?
By copy-pasting, you tightly coupled your test logic with your application’s UI state. The moment the UI state shifted, your tests broke globally. By abstracting the login process into a reusable component, we decouple the prerequisite (logging in) from the objective of the actual test case.
The Solution
We will create a Custom Keyword. This turns your login sequence into a reusable block of code that looks and acts just like a native Katalon command (e.g., WebUI.click).
Step 1: Create a Package and Keyword
-
In your Katalon Object Repository/Tests Explorer, navigate to Keywords.
-
Right-click > New > Package (Name it com.helper).
-
Right-click your new package > New > Keyword (Name the class LoginHelper).
Step 2: The Custom Keyword Code
Paste the following code into your LoginHelper.groovy file. This function accepts a username and password as arguments, making it dynamic.
Groovy
package com.helper
import com.kms.katalon.core.annotation.Keyword
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
import com.kms.katalon.core.testobject.ObjectRepository
public class LoginHelper {
/**
* Log into the application using specified credentials
* @param username
* @param password
*/
@Keyword
def loginToApplication(String username, String password) {
// Opens the browser and navigates to your base URL (defined in your execution profile)
WebUI.openBrowser('')
WebUI.navigateToUrl('https://example.com/login')
WebUI.maximizeWindow()
// Interact with your existing Object Repository items
WebUI.setText(ObjectRepository.findTestObject('Object Repository/Page_Login/input_Username'), username)
WebUI.setEncryptedText(ObjectRepository.findTestObject('Object Repository/Page_Login/input_Password'), password)
WebUI.click(ObjectRepository.findTestObject('Object Repository/Page_Login/button_Submit'))
// Optional: Verify login success before proceeding
WebUI.verifyElementPresent(ObjectRepository.findTestObject('Object Repository/Page_Dashboard/header_Welcome'), 10)
}
}
Step 3: How to call it in your 30 Test Cases
Now, instead of copy-pasting 6 lines of code into every test, your test cases will start with just one simple, clean line.
In Script View:
Groovy
// Call your custom keyword at the start of any test case
CustomKeywords.'com.helper.LoginHelper.loginToApplication'('my_user_abc', 'my_secure_password')
// Continue with your actual test steps below...
WebUI.click(ObjectRepository.findTestObject('Object Repository/Page_Dashboard/btn_CreateReport'))
In Manual View: If you prefer Manual View, simply click Add > Custom Keyword, select loginToApplication from the dropdown, and pass your username and password into the input cells.
Why this saves your project:
-
Single Point of Maintenance: If the login URL or object IDs change, you edit them only inside LoginHelper.groovy.
-
Readability: Your actual test cases stay focused on what they are actually trying to test, rather than being cluttered with setup steps.
Note: If its require for every testcase you can explore Test Listner as well.