Introduction
Test Objects are one of the most important components of a successful automation project. Some are static (do not change at all), while others are dynamic (they are dependent on some dynamically changing parameters). This tutorial demonstrates various approaches for dealing with various types of test objects.
Requirements
In the Script view, you should be able to write your tests. You should also be familiar with the fundamentals of Java/Groovy.
Static Objects
Handling static objects is relatively simple. Simply pick New Test Object from the Object Repository and enter your preferred selector (I prefer XPath, so all my examples will be for XPaths, but the approach is the same also for other selectors).
Dynamic Objects
Dynamic objects are more difficult to deal with than static objects, but they are not as difficult as they appear. There is a Katalon method for dealing with parameterized objects, but I’d like to discuss some alternative approaches.
In a test case, define your test object directly.
The simplest way to create a test object. Here’s an example of code:
String dynamicVariable = 'DynamicId'
String xpath = '//div[@id="' + dynamicVariable + '"]'
TestObject object = new TestObject("objectName")
object.addProperty("xpath", ConditionType.EQUALS, xpath)
WebUI.click(object)
The first two lines, excluding the import statements, are straightforward: create a String variable ‘dynamicVariable’ and store it in another String – xpath. The next two lines are where the magic happens. You make a new TestObject instance (let’s call it object). Then, using the method addProperty, you assign your selector to this new test object (String selectorType, ConditionType type, String selectorValue). Finally, you use the test object directly in Katalon’s default keywords. Please see the API documentation for more information on ConditionType.
Extracting dynamic selectors into separate keywords is a better way to handle them. In your test project, you can have several keywords, each one for a single page or so. It is entirely up to you.
I’ll demonstrate a simple keyword with dynamic selectors.
public class MySelectors {
public static final String dynamicIdPath = '//div[@id="%s"]'
}
As you can see, the path is similar to the previous example, but there is one minor difference. For the String.format() method, I use the %s wildcard instead of a variable. Let’s make the necessary changes to our original test case.
String dynamicId = 'dynamicString'
String xpath = String.format(MySelectors.dynamicIdPath, dynamicId)
TestObject object = new TestObject("objectName")
object.addProperty("xpath", ConditionType.EQUALS, xpath)
WebUI.click(object)
As you can see, the only difference is on the line that defines xpath. Please consult the Java documentation if you are unfamiliar with String.format().
You can also use your own wildcard in the selector value. Then, instead of String.format(), use String.replace().
public static final String dynamicIdPath = '//div[@id="<<dynamicId>>"]'
// a line in test case:
String xpath = MySelectors.dynamicIdPath.replace("<<dynamicId>>", dynamicId)
The benefit of storing dynamic selectors in separate keywords is that all selectors are kept in one place. When a selector is changed, only one test is affected rather than all tests where it is used.
A method that returns a dynamic test object should be created.
We now extend the MySelectors keyword with a new method that returns TestObject. This will remove a few lines of code from your test case, making it easier to maintain.
public class MySelectors {
public static final String dynamicIdPath = '//div[@id="%s"]'
public static TestObject getMyTestObject(String selectorType, String selectorValue) {
TestObject object = new TestObject()
object.addProperty(selectorType, ConditionType.EQUALS, selectorValue)
return object
}
}
And our test case will look like this:
String dynamicId = 'dyanmicString'
String xpath = String.format(MySelectors.dynamicIdPath, dynamicId)
WebUI.click(MySelectors.getMyTestObject("xpath", xpath))
We can use the default Katalon keywords to call our new method because it returns TestObject. You do not need to worry about creating a new instance of TestObject in the test case. You can change it however you want; you can add more parameters (such as ConditionType) or simplify it by passing only a TestObjectProperty instance.
