Test Object Refactoring

Hi All, we are facing issue with UI object maintenance. we have so much duplicated object as we started with record and playback approach. Now we want to rework on our object repository and remove duplicate objects. Is there any way to directly change the reference from one test object with another ? lets say I have 2 test object …1. Login_Button and someone also created duplicate object which is Login_Button (1) so i want to remove all reference for Login_Button (1) from all Test cases and point it to Login_Button . is this possible ? @Katalon_team @Russ_Thomas @kazurayam @bionel @grylion54

@sumiranraut96

I have already answered to your question at

As far as I see there is no easy way to refactor a mass of duplicating Test Objects you created.

I would like to hear from others whose name were mentioned by @sumiranraut96

yeah this question was more specific about changing the reference of test objects’ to test cases. anyway Thanks @kazurayam . one qq was reading your code that you posted in my previous post. so in that are we just printing the content of .rs files in the form of json ?

That is a misunderstanding.

My code shows how to convert the contents of *.rs files under the “Object Repository” folder into a List<TestObject>.

Once you got a List<TestObject>, you can implement a variety of filtering ---- sort TestObjects with any key you like, select a set of TestObject with a single Locator value, etc.

Suprisingly enough, the Katalon API does NOT provide this feature natively.

This fact proves, I think, that the Katalon developers had NEVER imagined a situation where users may create thousands of Test Objests (with duplicates) and users want to refactor the mass with the DRY principle in mind.

I suppose, you would want a report of reverse reference from TestObject to TestCase.

The following post of mine may give you an idea:

Thanks @kazurayam for all your help. will check and post if i have any question .

@sumiranraut96 with all the effort you put into writing detailed questions (not ignoring the extra effort expended by Kaz) you would be much better off spending that time switching your Test Cases to use a POM and makeTo()like I said.

@vu.tran @vu.le @Coty @sara.leslie

And in support of @kazurayam’s point , it’s high time Katalon put some effort into up-front education on these matters, that the OR as built by Web Recorder, falls far short of expectations and will not produce the most efficacious results. Either that, or stop promoting it so heavily up-front. All it achieves is a huge amount of work to undo its worst excesses – that and a plethora of threads like this one.

Katalon Marketing: Web Record is a great tool to develop Test Cases – you don’t even need to be a programmer!

Me: In three months, you’ll hate what it’s done for you and the work it will take to put it right.

3 Likes

Extremely sorry @Russ_Thomas if its getting irritating for you. :slightly_smiling_face: regarding your 2 solution . I think POM may not be suitable for us considering technical capabilities of our team member. I loved the idea of makeTo or creating your object directly in test case. I just have one question on that . how about the maintenance ? when something gets changed we will need to change those new changes in every test case . right ? or let me know if i am missing something

I think it would come down to how well you organize your POM and your method names to your objects (edit: and the state of your objects if they should change during your testing, such as after a Save). As you would have to change the pathway in the OR for any changed objects (hopefully, one object one change), you will have to change the pathway (again, hopefully, one object one pathway) in the specific method to your object. It would come down to organization and having a naming policy to your POM methods.

Let me go back to the question in the original post, as I haven’ replied to it.

No, Katalon Studio does not equip such “Test Object Refactoring” feature at all.

Your question reminds me of the refactoring features provided by IDEs. For example, IntelliJ IDEA support a refactoring support for Java programs.

I guess @sumiranraout96 requires something like this for Test Objects and Test Cases in Katalon Studio.

Unfortunately there isn’t.

Your are right. When the target HTML gets changed, we will need to change our test code anyway. We can not nullify the maintenance cost of testing software which looks into the elements in HTML pages in detail.

We have discussed 3 possible ways:

  1. If you have Test Objects in the Object Repository, you need to maintain them.
  2. If you wrote many statements in Test Cases that call makeTO(locator), then you need to maintain them.
  3. If you have Groovy Classes as Page Object Model, then you need to maintain them.

My view:

Efforts involved for getting started with: Way 1 < Way 2 << Way3

Effors involved for maintenance long term: Way 1 > Way 2 >> Way3

Apparently you are worried about the efforts required to maintain your tests in case of changes in the Application Under Test (HTML pages). I think the best way to avoid it is: “Don’t look into the detail of HTML elements”.

An alternative approach is available: “visual testing”. I am aware that you, @sumiranraut96 , once asked Katalon TestOps Vision. So I suppose you are aware of what “visual testing” is. In a visual testing you will take screenshots of a web page at least twice; compare them; find any visual difference. As for “visual testing” you would create very little of Test Objects, or maybe even none. Since you create very little Test Objects, the efforts required to maintain the visual testing suite would be small.

I would rather suggest to you, @sumiranraut96, to leave your current test asset as is.

Rather, you should change your mind fresh and look at “visual testing”. Why not you try to build a new set of Visual Testing? If you could build a visual testing suite that fullfill your business requirements, then you can replace significant portion of your current set of tests with the new visual testing. Then you can erase significant portion of your 15K+ Test Objects. A strategic withdrawal.


Another “Visual Testing” tool : Applitool

I find this article is nice to read to understand the “Visual Testing” concept.


A few weeks ago there was a post

This told me of a company ‘Eggplant Software’. I think there project is a sort of “visual testing” tool. They claim their product is widely used, easy, fast, AI-driven, … more and more. You might be interested in it.


There is another Visual Testing tool named Percy:

I have my own implementation of “Visual Inspection”

I use this when necessary. So I do not need TestOps “Visual Testing”, I do not need “Eggplant”. I do not need “Percy” either.

My product is free to reuse if you like, but requires you to be a skilled enough Java programer .

That’s not the case at all. You’re the “injured party”, not the cause.

One thing is true: things change. When they change, you have to adapt the Test Case code to the change.

However, with a workable POM, you will have (usually) ONE class per web page. That class has all the Test Objects built ready to go. In your Test Cases, you refer to those prebuilt Test Objects. So for ONE button, makeTO() only appears ONCE in your class code.

class MyWebPageClass() {
  TestObject toMyButton = makeTO("...")
  TestObject toNameField = makeTO("...")
  // etc
}

Then you just import your package/class into your Test Cases.

TLDR: sue me. too much fuss.
i will sumarize this topic in few words.

  • OP creates an awfull project most probably because was to bussy to read the docs in due time…

  • Now OP is asking for help but is too proud to admit he did something stoopid, therefore whatever solution is proposed it is not acceptatble…

  • In the mean time more brilliant minds came with other abominations as ‘solutions to be implemented’ without having any clue how to solve it…

did i missed something?