WebUI Test Object - Best Practice

Hi All, we are using katalon as our testing tool since more than 2 years. initially everyone was very new to automation and we relied on record and play approach which resulted in huge test object which are redundant as well as repetitive. Katalon provides a way to delete the unused object but the duplication still remains an issue . can someone suggest some articles or provide links on Best practices to maintain test object in katalon . you can share your own view as well. Thanks @Katalon_team @Russ_Thomas @kazurayam @ThanhTo

1 Like

For various reasons, I’m not a fan of the phrase “Best Practice”. So I can’t hand-on-heart tell you what is “best practice”. However…

I never use the Object Repository (OR) – mine is completely empty. If I need a Test Object, I create one, live, in memory, during the test. I use a custom keyword makeTO().

Using the Recorder, you’ll have a worthless struggle on your hands trying to maintain a robust and meaningful set of targets. I honestly can’t imagine the pain you go through just to maintain the OR, all before you get to write a line of test case code.

Starting today, rewrite your TOs to use makeTO(). Build a Page Object Model (POM) by hand and start testing like a pro. :sunglasses:

Note. The published copy of makeTO() is written to use css. You can easily modify it to use xpath by changing “css” to “xpath”, if you wish.

1 Like

Thank you so much @Russ_Thomas . yeah the struggle is real. our repository takes 15-20 min to load and its not katalon fault. The solution you have suggested is really good. I am not sure how feasible it would be for us to move completely to POM as we already have 15K+ objects residing in our repo. I am afraid that the same thing will continue which will create redundancy and duplication. what would you have done if you were at our place given that we have 15K+ object already and now wanted to somehow streamline the process?

:scream:

Hard to say because I’m not/ was not in that position. In my early days using Katalon, I very quickly realized the OR doesn’t scale. So I looked into what a TO actually is and decided to roll my own and ditch the OR.

1 Like

Best practice to maintain test objects is to not use them at all.
For WebUI testing, follow a POM approach.
For API testing … yeah, you may use such, but keep them as a minimum.
Use generic ones, parameterized so you can re-use them (e.g one for each http verb).
You don’t need more than this.

If you will set your mind to design your test-cases in a ‘given - when - then’ structure, even if you don’t actually use the BDD feature, you will figure it out how such can help.

1 Like

Thanks @bionel for your suggestion. I never worked on selenium so not that much aware about POM on a very detailed level . How to implement POM in katalon ? (Manage Web Test Objects | Katalon Docs) does this method considered as POM. or do we have any other way in which we can implement the POM in katalon ?

Search the forum and you may be surprised that you can find various approaches and plenty code snippets.

Thanks @bionel . will do

In the Product Forums section below your question, you have “Katalon-Recorder”. Are you really using Katalon Recorder or are you using the Web Recorder of Katalon Studio? They are two different products.

Personal Opinion using Katalon Studio (not Katalon Recorder)
I still use the OR, so I don’t think you have to give it up completely. However, I have had to go through a reorganization from when I first started experimenting/learning with KS and how I use it now. I still have one folder for each web page in the OR. I give my objects a three part name to describe the element’s type, or tag, which section of the web page it belongs and an appropriate name based on the nearest label.

I hope it’s simple and organized enough for the next person to take my position and continue on.

1 Like

@grylion54 I am using web recorder - Record Web Utility | Katalon Docs. hmm even we thought of reorganization but not sure if its kind of too late for us with 15K + Object and 2000 test case already present in our repo. what would you suggest

As I stated above, I won’t be continuing in this Testing position, so I have hopefully made it convenient for the next person or persons–and I’m only around (down to) 6.5K elements. :slight_smile:

Maybe experiment with “converting” one web page and see if it is worth it, although it will likely be time consuming doing the conversion. But, see if you like the final “effort”.

Hmm I agree. Thanks @grylion54 for your valuable inputs

I guess that you have tons of duplicating Test Object with different id but with the same locator (XPath expression or CSS Selector). I would guess that you can shrink the existing 15K+ objects to smaller size (e.g, 1K) if you could eliminate all the duplications. The DRY is the primary principle you should follow in managing Test Objects in Katalon Studio.

I am afraid that the Web Recorder tool of Katalon Studio does NOT have the DRY principle in design. Rather it lets you innocently violate the DRY principle. It makes you, non programmers, be careless enough to creates tons of duplicating Test Objects. Personally I do not use the Web Recorder tool at all because of this unthoughtful design. The Web Recorder is nice to get you started with WebUI test automation. But you should not rely on it long. As soon as you start building test suites of good size, you should stop using the tool.

I agree with @grylion54’s opinion.

I too give a folder tree of Test Objects that corresponds to the structure of URL of the web pages. This is critically important to eliminate disorder and duplications. Please find an example of my project:

Please find subfolders auth, LogInPage plus a Test Object “input_Log in” corresponds to an <input type="text"> field with label “Log in” in a web page at the URL http://<hostname>:<port>/auth/login :

I suppose you would want to learn and apply the “Parameterize Web Test Objects” to reduce the number of Test Objects as well.

Katalon Studio offers no help to find duplicating Test Objects. You need to find them by your deep thinking or developing tools for yourself.

Once you identify which Test Object should be renamed or removed, then Katalon Studio offers a bit of help — it will automatically rewrite the references within the Test Case scprtis to the Test Object.

Hard job, I suppose, but you can do it if you really want to.


The following post tells my view about Project Object Model in Katalon Studio:

@sumiranraut96

POM is a pattern of Object Oriented Progragamming. It requires seasoned programming skill in Java/Groovy. I guess that POM is not the way you can take.

3 Likes

I wrote:

I would give you a starter for developping tools for you. See the following GitHub project.

My com.kazurayam.ks.ObjectRepositoryRetriever class reads the XML config files in the Object Repository folder and returns a List<TestObject>. My demo test case converts each TestObject instance into JSON text and prints them like this:

2022-08-03 23:26:39.893 INFO  c.k.katalon.core.main.TestCaseExecutor   - --------------------
2022-08-03 23:26:39.897 INFO  c.k.katalon.core.main.TestCaseExecutor   - START Test Cases/testObjectRepositoryRetriever
2022-08-03 23:26:40.616 DEBUG testcase.testObjectRepositoryRetriever   - 1: projectDir = Paths.get(getProjectDir())
2022-08-03 23:26:40.636 DEBUG testcase.testObjectRepositoryRetriever   - 2: testObjects = ObjectRepositoryRetriever.readTestObjectFiles(projectDir)
2022-08-03 23:26:42.483 DEBUG testcase.testObjectRepositoryRetriever   - 3: assert testObjects.size() > 0
2022-08-03 23:26:42.487 DEBUG testcase.testObjectRepositoryRetriever   - 4: println(testObjects.size())
19
2022-08-03 23:26:42.495 DEBUG testcase.testObjectRepositoryRetriever   - 5: testObjects.forEach({ java.lang.Object to -> ... })
null
{
  "isParentObjectShadowRoot": false,
  "properties": [
    {
      "name": "id",
      "condition": "EQUALS",
      "value": "comment",
      "isActive": true
    }
  ],
  "xpaths": [],
  "objectId": "Page_AppointmentConfirmation/lbl_Comment",
  "useRelativeImagePath": false,
  "selectorMethod": "BASIC",
  "selectorCollection": {}
}
{
  "isParentObjectShadowRoot": false,
  "properties": [
    {
      "name": "id",
      "condition": "EQUALS",
      "value": "facility",
      "isActive": true
    }
  ],
  "xpaths": [],
  "objectId": "Page_AppointmentConfirmation/lbl_Facility",
  "useRelativeImagePath": false,
  "selectorMethod": "BASIC",
  "selectorCollection": {}
}
...

You would want to extend my sample code so that it helps you finding duplicating TestObjects.
How to do that? …well, I do not know. It is your homework.

1 Like