Hello!
I have used Katalon Studio for about three months and most of the time used the Object Repository for storing test objects. I recently discovered the ability to create test-objects on the fly in the test scripts. (Using a Custom Keyword). My question is:
Are there any drawbacks to creating test-objects this way? My experience is that I have less problems with frames etc. I was hoping on some input with pros and cons before I rewrite all of my projects.
Alexander
the biggest con not using the object repository is that, when a selector to an object changes(for example, new id), you will have to change it for every step definition that needed that specific test object, as opposed to updating the selector in the object repository
If your custom keyword resides in a class designed to capture or wrap the details of a page and its component parts, then that class acts like an object repo for that page and its components. This is “standard practice” when adopting a POM (page object model).
IOW, the point @kenzie.rigole is making only applies if you create your test objects per test case.
Thanks for replying.
I have not implemented the concept you are describing @Russ_Thomas, but this seems to be something i could look into. What are the pros and cons of using POM instead of the OR.
Regards,
Alexander
The OR is essentially Katalon’s interpretation of a POM. While I would argue that it is not really a true POM implementation, the OR is designed to work hand-in-hand with the Recorder.
If you aren’t using the Recorder, there’s no real good reason to use the OR over implementing your own page objects (again, IMO).
I almost never use the recorder and I find the OR unmanageable because my projects a of significant size.
I still want to create and use test-objects rather than JavaScript etc. I am currently creating a custom keyword for each page, which includes several methods for creating the wanted test-objects, like this:
I then call the needed method in my test - cases to create a test-object to interact with. Regarding your input @Brandon_Hein: Is this considered an implementation of POM? and Is there any other effective way of doing this?
I then call the needed method in my test - cases to create a test-object to interact with.
Just so I’m clear, your page objects just have methods for creating test objects, yes? Then you are calling these keywords from your script to get test objects, which you then use to perform work (i.e. click(), sendKeys(), etc.)?
Is this considered an implementation of POM?
This is totally fine, and essentially replaces the OR with your own custom containers.
and Is there any other effective way of doing this?
Yes, there are plenty of ways to approach it. With any automation, these are the “big 3” items that you must handle to make scripts run smoothly and consistently:
1.) Location of elements
2.) Manipulation of those elements (clicking, sending keys, etc.)
3.) Waiting for the page to respond
Personally, I prefer that my page objects wrap all 3 of these, not just the location of elements as you are doing.
For an easy example, take a login page for some application. This page object might have 3 (or more) methods:
public class LoginPage {
public void setUsername(String value) {
// locate username field
// set the value
// wait for page response (if any)
}
public void setPassword(String value) {
// locate password field
// set the value
// wait for page response (if any)
}
public void clickLoginButton() {
// locate login button
// click
// wait for page response
}
}
Then your script-writing becomes super easy. Want to set the username/password field, then click the login button? Call the appropriate methods, and the page object does all of the work for you; no extra thought required.
This opens up a lot of customization too. What if the usual click() method works for some buttons in your application, but not others? What if you need JavaScript to do some work in some part of the app? What if your wait condition works in some places, but not others? You don’t want to have to remember these kinds of caveats in each script you write, so having your page objects responsible for these things will save you a lot of headache.