Object Repository / Recording vs Manual - Best Practise

Currently, I tend to record test scripts, which in turn creates new test objects and folders. Over time, as I’ve recorded more tests within the same project, I have numerous duplicated folders and test objects.

Whilst I can create new scripts very quickly, and save time (not) maintaining my Object Repository this way, the main downside is that if a page item’s properties change, I would have to update several test objects (not to mention that the Object Repository is very confusing with so many items now).

The alternative as I see it would be to manually create each and every required page object, and manually enter each click / verify etc. command, choosing an existing page object whereever it exists (or else creating a new one)

Is this (manual object identification and test script creation) generally the best practice?

I realise this is one of those ‘it depends’ answers, so I’d be really grateful if anyone could explain their workflow around these areas, and how you create and organise your test automation.

Thanks :slight_smile:
Kevin

Hi Kevin

Currently, I tend to record test scripts, which in turn creates new
test objects and folders. Over time, as I’ve recorded more tests within
the same project, I have numerous duplicated folders and test objects.

Whilst
I can create new scripts very quickly, and save time (not) maintaining
my Object Repository this way, the main downside is that if a page
item’s properties change, I would have to update several test objects
(not to mention that the Object Repository is very confusing with so
many items now).

You’ve come to the right conclusion, summed up by “the OR does not scale”.

The alternative as I see it would be to manually create each and every
required page object, and manually enter each click / verify etc.
command, choosing an existing page object whereever it exists (or else
creating a new one)

Yes, that sort-of works, to an extent.

Is this (manual object identification and test script creation) generally the best practice?

It depends :smiley: Opinionated viewpoint coming… ready?

            _I don't use the OR at all._  

In my not so humble opinion, it’s a waste of time, a terrible waste of resources and (sad to say) completely unnecessary (if you’re comfortable in code). It’s like flying to London from New York via Cape Town.

I’d suggest you either…

1 - Create ONE SINGLE test object (“dummy” or whatever you want to call it) and modify its properties, live, in your test script(s). See:

https://docs.katalon.com/display/KD/[WebUI]+Modify+Object+Property
https://docs.katalon.com/display/KD/Change+CSS+selector+of+an+object+at+runtime

Or

2 - if you’re comfortable working in Script mode, dispense with the OR completely, and make your own TOs, live at runtime. See:

https://docs.katalon.com/display/KD/Creation+of+Test+Object+in+Object+Repository+in+Runtime

3 Likes

Hello Kevin,
so i actually like that Katalon is trying to teach/force you to use pattern of separating page logic from page description. (and 2nd pattern separating page logic from business logic by using user keywords)
We are using manual creation of objects with xpath manually defined by tester. This will allow test to be readable even for beginner in tabular view, so he/she can learn what test is doing and on what objects.
Also, it force you to keep repository clean - without lot of duplicates. And in case page changes, we need to go to particular page and change affected definitions.
In project we have objects stored by “Page” and separate folder for common objects seen from anywhere.
It take some time when you define them (TO in repository), but it pays off when you try to maintain automatic tests while application is still under development.(But i will be more than happy if creation will be possible on less clicks and actions than now)
What i also do for myself, is i describe test in plain text as series of lines in apostrophes when i actually add script line directly after such text line it becomes description of that step


and description is part that is transferred to JIRA in case of automatic bug creation on test fail

2018-07-10_17-42-57.png

2018-07-10_17-43-54.png

2 Likes

Thanks both for your comments, very interesting stuff.

Russ, I’d actually come across your post previously, about creating a dummy object and not using the object repository as such. However, although reasonably comfortable in code, I’m not a developer in test as such, and also the framework could one day be used by non-technical testers, so I want to keep things simple and rely on working in manual mode.

I think I can see clearly now that ‘Record Mode’ is not something that will work out in the long-run, and in fact I’m now running into issues where my ‘recorded’ objects have too many properties that are detecting the object, resulting in object recognition failures. I think I’m better off with the chore of manually identifying all objects, with a single property where possible, which I think will save me time later - in the long run, not least in terms of not having to organize the duplicate items where I ‘re-record’ on the same page/objects.

Andrej, I think this is also what you’re saying, and it’s an interesting point you make about having one folder for each page, and one for common objects (in my case there are an awful lot of common objects (e.g. Logout, Settings etc.) that are accessible from most pages).

I like your idea of adding comments too - I will adopt that.

Thanks both for your help (and apologies for the very slow reply to my own topic!).

1 Like

Russ, I’d actually come across your post previously, about creating a
dummy object and not using the object repository as such. However,
although reasonably comfortable in code, I’m not a developer in test as
such, and also the framework could one day be used by non-technical
testers, so I want to keep things simple and rely on working in manual
mode.

An unwieldy OR is anything but simple and a huge time-sink to maintain. But I hear you…

I think I can see clearly now that ‘Record Mode’ is not
something that will work out in the long-run, and in fact I’m now
running into issues where my ‘recorded’ objects have too many properties
that are detecting the object, resulting in object recognition
failures. I think I’m better off with the chore of manually identifying
all objects, with a single property where possible, which I think will
save me time later - in the long run, not least in terms of not having
to organize the duplicate items where I ‘re-record’ on the same
page/objects.

Zackly. B) That’s pretty much the top and tail of it.

And as for one folder per page, that applies to the OR (should you choose to go that route) and your Test Cases, IMO.

And as for one folder per page, that applies to the OR (should you choose to go that route) and your Test Cases, IMO.

YUP. And would be nice to use Test Suites and Test Suites Collections for representing business logic of application.

Kevin,

in fact I’m now running into issues where my ‘recorded’ objects have too many properties that are detecting the object,

I would tell you why Katalon’s Recorder/Spy generates so many unnecessary locators for test objects. Open Project > settings > Test Design > Web Locators. You will see the following dialog.

Please find all of locators are checked ON as default. This is the reason why so many unnecessary locators are generated.

I would rather have id, name, text left ON, while others (alt, checked, form, href, placeholder, selected, title, linked_text) turned OFF. This would help reducing amount of work for deleting stuff generated by Recorder/Spy.

so_many_unnecessary_locators.png

1 Like

I added this post for improvement:

problem is, what turn off? because this usually heavily depends on project. i have one project where i can left ON id and everything else can be turned OFF, but on second one i rather left everything ON since there is no clear choice. And i have some experience in automation. Imagine someone who just start. I agree with revision, but it should be revision of code that is generated. In many cases it’s too complicated to work correctly.

In many cases it’s too complicated to work correctly.

I agree.