Hi everyone,
I’m working on a dynamic web application where the controls change every time I click the Submit button. Unfortunately, the elements I’m trying to interrogate do not have any unique attributes (like IDs or consistent class names), which makes it difficult to identify them reliably.
website link
Since there’s no unique identifier, I tried using the Select Element option in interrogation. I noticed that a stable parent exists three levels up from this element. I would like to anchor my control using that stable ancestor, but I’m unsure how to do it correctly in Pega Robotics.
Has anyone encountered a similar issue? Is there a way to reliably anchor a dynamic element by navigating a few levels up the DOM during interrogation or using match rules?
Any suggestions or best practices would be greatly appreciated.
Thanks in advance!
Doc1.docx (214 KB)
@narendranathanv
After looking at this particular website (https://www.theautomationchallenge.com/), my observation is that this really isn’t something worth practicing with. I would focus on a more functional web application or a real application you might wish to automate. It is possible to automate this application, but there just isn’t much value on this specific application in my opinion. I have never encountered a web application whose layout was deliberately misleading to not only the user, but to automation tools. Dynamic, certainly, but deliberately confusing is not something I have ever encountered.
As for your original question though, the way I would handle a web application where controls do not have specific IDs or other attributes that identify them would be to use a container to uniquely identify them. That doesn’t work with this page however, as they deliberately separate the labels from the text boxes, but that wouldn’t likely be the case in a real application. Those would almost certainly be grouped together for styling purposes. If the label and the text box were both beneath a container, then you could use the text property of the container to uniquely identify it and then a generic match rule for the text box since it would be the only one in the container. For example, I would interrogate a container control (likely a DIV that encompassed the label and the text box). You could easily find this by using Select Element as the interrogation mode. Once you have the container, give it a text match rule that contains whatever text the label has. Next, interrogate the text box and give it a simple type match rule. This is akin to telling a valet that your vehicle is parked in a specific numbered parking space (A-57 for example). In this example, the valet knows nothing about your car, but it is the only one that can possibly be in that space and thus they are able to locate it simply knowing it is a vehicle.
I haven’t yet completed automating this site, but given it is timed, I believe the fastest way would be to interrogate the label and the text boxes with UseKeys enabled and then write a script to match them up based on their locations. That is something I have only ever had to do once where I saw a nested table layout with tables visually inside of other tables, but in the HTML, they were actually siblings. This meant that each outer row appeared as a parent of the inner table, but it was actually not a parent. I ordered both lists and used their coordinates to associate them, but that was a first for me in nearly two decades and the only time I have ever seen a layout where controls where not associated with each other on a web page in any way but visually.