What makes a good selector? Should I just accept the defaults that UiPath gives me?

News Vote on Tutorials
, , , , ,
1

A good selector includes properties that uniquely identify a UI Element, and only properties that are unlikely to change. (Or at least the least likely to change)

In many cases, the default selectors are fine. Depending upon the application, however, it may be necessary to make some - or even a lot - of changes. It is important always to analyze the selector UiPath gives you against my first answer above. Did UiPath give you a selector that includes good properties?

Some properties I avoid where possible, when automating in a browser:

  • css-selector
  • class
  • id
  • idx

These are likely to change on a web page, especially css-selector and class. CSS is very dynamic and web developers use it to change how things look and function, on the fly while the page is being used.

If you have an idx in your selector, it is important to edit the selector to uniquely identifying properties so that can be removed. Anchors can also be used to eliminate the need for idx, along with Computer Vision and Image selectors.

Today I’m working in an app that is quite painful to automate in - SalesForce. UiPath has a good document on automation in SF:

I have a SF page with a button that was clicked and a popover layer appears with a small form - a pulldown and two text boxes. The Name box is disabled until you make a selection in the Category pulldown.

image

I’m going to leave out the top level of these SalesForce selectors because they have a sfl-path property that is unique to SF. I’ll just show the rest of each selector that’s more standard.

Here is the fuzzy selector UiPath gives me for the Category pulldown:

<webctrl tag='IFRAME' /> <webctrl tag='INPUT' type='text' class='docTypeCustomField input-sm checkbox-inline form-control nc-pristine ng-dirty ng-touched ng-empty ng-invalid ng-invalid-required' aaname='' />

Look at that class property, there’s no way I’m going to trust that. So I open up in UI Explorer and see:

image

Ironically I said earlier that I try to avoid id, but in this case it’s the lesser of two evils. id is less likely to change than class. So I add id by checking its box. Unfortunately class doesn’t actually show in UI Explorer, so I have to manually delete it from the indicate window.

<webctrl tag='IFRAME' /> <webctrl tag='INPUT' type='text' id='docTypeInputField' />

This is my final selector, but it seems pretty generic and I don’t trust that id property, so I’m going to add an anchor. Here is the selector it gives me for the anchor:

<webctrl tag='IFRAME' /> <webctrl tag='LABEL' type='' class='slds-form-element__label form-control-static input-sm slds-show--inline slds-var-p-top_x-small' aaname='Category' />

Obviously I don’t like that class property, but aaname is great. Any time you have aaname I highly recommend using it. It’s very likely to stay the same. So this is my final selector:

<webctrl tag='IFRAME' /> <webctrl tag='LABEL' aaname='Category' />

Notice I also remove the ones that are blank, like type='' - not a fan of empty selector properties. And I also set the accuracy to 90 instead of the default 50. Wish there was a way to change this default.

Also, the Window selector includes the customer name which is part of the page title, so I wildcard out the customer name with an *.

Now I have selectors that I am confident will properly identify the UI Element, and (hopefully) be resilient to any changes made to this system because SalesForce is frequently updated and things under the hood often change.

4 Likes