ID of input elements keep changing and are cryptic. How can I overcome this

Hi I am trying to build a script for automated testing and hit a bottleneck, I realized that I cannot use the id or other attributes on the input tag to identify what should be entered.

There is one thing that I could uses The label node precedes the input and reflects what the input is expected to contain. And the second element is supposed to contain a location. There other elements like text area that needs to be populated with data.

Here is what I was thinking with reference to this example. -

Find the input elements. Also find the label element and add an attribute to the input element. (say add a attribute - label)
Now, loop through the rows in the spreadsheet and populate the input elements and save the page.

I am not sure how this can be accomplished. Given that I plan to send multiple transactions to the page, do I even need to add any objects to to Object repo to build a spreadsheet?

Any points will be highly appreciated.
Thank you for reading my message!

A simplified version of the html. I have cut and pasted part of the html to show why I cannot use any attribute as a selector. There are 2 input elements with the corresponding Title and Location labels. There could be other input types as well.

  • **Title**
    Title
    ****
  • <**label id="56$20999--uid99-formLabel" data-automation-id="formLabel" for="56$20199--uid99-input">Location**
    Location
    ****

Hi Sandy

No, you don’t need to add Test Objects to the Object Repository for each element (I’d strongly advise that you don’t). You can create a temporary Test Object “live” at runtime for each input you want to target.

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

As long as your “simplified” copy of the HTML reflects the structure of the actual HTML on the page, the following CSS selector will target the input elements:

li.WFAO.WLBO input

If you want to target each input separately:

li.WFAO.WLBO:nth-child(1) input
li.WFAO.WLBO:nth-child(2) input

Hope that helps.

Hello Sandy
xpath selector can be:
for labels and inputs respecively
(and i suggest to define them in Obj.Repository so you keep everything readable (in tabular view) until you reach level where you find O.R. too binding)

(//li[@class="WFAO WLBO"]//input[@data-automation-id="formLabel"])[1]
(//li[@class="WFAO WLBO"]//input[@data-automation-id="formLabel"])[2]
(//li[@class="WFAO WLBO"]//input[@data-automation-id="textInputBox"])[1]
(//li[@class="WFAO WLBO"]//input[@data-automation-id="textInputBox"])[2]

Thanks Russ and Andrej, will try both approaches.

Russ. any reason you are advocating not including the objects in object repo?

Also, is there a way to make this dynamic. For example loop through all the intput, map it to the label object and then pass values according to the label associated to the object?

I do not have control over the position of the objects and am worried that if the vendor changes the position of the objects or perhaps added new input objects on the page, the hard coding of the input position numbers will cause issues.

Thanks for your inputs.

Both approaches will work. I don’t do xpath (just a personal preference; I find it too “wordy” and therefore “noisy”). Plus, I know CSS well, xpath, not so much B)

Re the OR…

Seriously, if you’re going to fly from New York to London, would you really start by taking a cruise ship to Cape Town?

The OR can (and usually does) grow very quickly. It soon becomes a burden to manage and control (even moreso if you use the recorder). I keep on keeping on about this :wink: It simply does not scale. In my (not so) humble opinion, it (and the recorder) should be redesigned from scratch.

If you like to access your HTML elements using an unnecessary set of wrappers (Test Objects) just create one, at runtime, when you need it, using the method I linked to.

WebUI.click(findTestObject("path/to/object"))  // needs pre-built TO in OR

WebUI.click(makeTO("#my-object")) // needs nothing

However, if you’re comfortable in code, dispense with Test Objects and the OR and target your HTML elements in JavaScript. i.e, cut out the middle man entirely. He’s not your friend. B)

1 Like

“The OR can (and usually does) grow very quickly. It soon becomes a burden to manage and control (even moreso if you use the recorder). I keep on keeping on about this It simply does not scale. In my (not so) humble opinion, it (and the recorder) should be redesigned from scratch.”

Ha ha. Aboslutely. I am new to this world. But can easily see that. Thanks for the suggestion!

I am encountering this error -

**FAILED because (of) Variable ‘ConditionType’ is not defined for test case.

**I created a custom keyword on the lines of the example provided. I had to change to ‘public’ instead of static.

Where amI going wrong?

public class UT {

/**

* Construct a Katalon-compatible TestObject in memory.

* @param css (String) The CSS selector used to find the target element.

* @return (TestObject) The constructed TestObject.

*/

@Keyword

public TestObject makeTO(String css) {

TestObject to = new TestObject()

to.addProperty(“css”, ConditionType.EQUALS, css)

return to

}

}

you need to insert the following line:

 import com.kms.katalon.core.testobject.ConditionType
1 Like

Thanks. Getting used to the error messsages.

I am new to the automated testing field and am seeing concerns that I wanted to share.

1. It looks like not all web apps are amenable to automated testing Especially those which are not developed inhouse and the identifiers are dynamic. There will be a need to update and testthe script for every release. If the testing is being done by development team, that will put additional burden on the overstretched development team.

2. Coming back to dynamic test objects, what is better Xpath search or CSS from performance,scalabilility and maintenability. Any links to CSS selectors? I have not worked on CSS.

3. I keep hearing stories of how small teamsimply gaveup on automated testing and decided to enter the test cases themselves manually. And this team develops the web app themselves.

4.Anyone using this tool for creating test data - the intention being to load date before running processes to extract data?

Hi Sandy

1. It looks like not all web apps are amenable to automated testing
Especially those which are not developed inhouse and the identifiers are
dynamic.

I’m not sure I agree with that statement. Some AUTs are challenging, yes. But as the answers posted on this forum can prove, even where IDs et al are dynamic in nature, there is usually a way to pin them down.

There will be a need to update and testthe script for every
release.

Of course. In fact, more frequently than that. We test against multiple development branches 24/7.

If the testing is being done by development team, that will put
additional burden on the overstretched development team.

Of course. If works needs to be done, it can only be done with adequate resources (which must include people, too).

2. Coming back to dynamic test objects, what is better Xpath search or
CSS from performance,scalabilility and maintenability. Any links to CSS
selectors? I have not worked on CSS.

From a performance perspective, CSS:

but do pay attention to the dates here. It’s possible some absolute metrics and results have changed though I’d suspect they’ve all moved pro rata and still favor CSS.

However, from a testing perspective, the speed of execution between CSS and XPATH are largely irrelevant: your test code needs to wait in units of seconds or large fractions of a second while the browser performs millions of operations on the page.

In terms of application of CSS/XPATH, you choose which best suits your purpose based on your own proclivities. I prefer to use the tools that the page is built from – excluding the HTML itself, that is JavaScript and CSS.

My only excursion into the world of XPATH was way back when it was relatively new – I worked on XSLT processors in XML and found XPATH a worthy tool. But that was 20 or so years ago and since my CSS and JS knowledge is longer and deeper, I now don’t need XPATH.

Aside: it’s frequently pointed out (to me, anyway) that CSS cannot traverse in reverse: i.e. there are no “parent” or “ancestor” rules in CSS. This is true. However, using JavaScript and CSS, it’s not an issue. And again, sticking to these two is using what the browser uses and using what the browser manufacturers focus on most when they try to improve their performance. Said another way, improving the performance of XPATH is of no benefit to end users – so why would they even bother to do it?

So, if anything, the metrics as published in that SO thread above are likely more in favor of CSS (and JS) today.

3. I keep hearing stories of how small teamsimply gaveup on automated
testing and decided to enter the test cases themselves manually. And
this team develops the web app themselves.

In my org, all developers do some testing (lower level unit testing). We also apply broader testing for “user stories” to the AUT as a whole (this is where Katalon is used).

4.Anyone using this tool for creating test data - the intention being to load date before running processes to extract data?

Kind of. I use specialized groovy classes (factories) to enter data into forms and verify the results and outcomes. These factories are consumed by multiple Test Cases. A Test Case then becomes the conductor, guiding the moves a user might make through the AUT and orchestrating the factories in the correct sequence(s).

I considered using data sources like CSV/Excel but decided that would be “one moving part too many”. Consequentially, I spend zero time thinking outside Katalon – i.e. I don’t need to “put my Excel hat on”, ever. I have no need to create a “mental map” between Excel and Katalon when thinking/reasoning about my data and code and its use by the AUT. And believe me, my AUT is huge – it handles a ton of user data which needs to be mocked up in my factories.

Hope that gave you some food for thought.

Hi Russ, For question number 1, Can you go into more detail about how you would pin down a dynamic ID button?

While in the future it can be changed to static, It would be nice to have a work around for now.

Hi Andrew

There is no “one size fits all” answer to that. But in general, there is generally a unique path (either via CSS or XPATH) which follows the structure of the HTML to reach the element in question. That path varies from case to case for obvious reasons.

The “trick” is to learn CSS or XPATH. Plus, learn your AUT structure.

Adding something to question n. 2:

I personally use CSS except in two cases
1. as Russ mentioned, CSS doesn’t traverse backwards, so when I need to find the ancestor of a given element (but this isn’t very often) i use Xpath
2. Xpath can easily find elements that contain certain text, so to find a div that contains text ‘Katalon Studio’, I use xpath expression //div[contains(., ‘Katalon Studio’)] (and yes, I know this can be done with JavaScript :smiley: )

Russ, Can you point me in the correct direction? The best tutorial link for leaning Xpath?

B)

2 Likes

Russ Thomas said:

http://lmgtfy.com/?q=xpath+tutorial

B)

Thank you!

a good page to get lot of info about web technologies (forgotten by time)
https://www.w3schools.com/xml/xpath_intro.asp