LocatorStrategy Fallback

[stonebranch2]

Hi Isomorphic,

We have a few questions relating to AutoTest and scLocator that I am hoping you can help clarify.

We have an scLocator, like follows.

//autoID[Class=Window||index=181||length=309||classIndex=1||classLength=2||roleIndex=1||roleLength=2||title=Windows%20Task%20Details%3A%20Ping||scRole=dialog]/item[0][Class="SectionStack"]/section[Class=SectionHeader||index=0||length=1||classIndex=0||classLength=1||roleIndex=0||roleLength=1||scRole=tab||name=isc_OpswisePanelDetailsSection_2]/item[Class=VLayout||index=0||length=1||classIndex=0||classLength=1]/member[Class=TabSet||index=0||length=1||classIndex=0||classLength=1]/tabPane[title=Windows%20Task||index=0]/member[Class=VLayout||index=0||length=9||classIndex=0||classLength=8]/member[Class=DynamicForm||index=0||length=1||classIndex=0||classLength=1]/item[name=name||title=Task%20Name||value=Ping||index=0||Class=TextItem]/element

If we take that scLocator, and use it with AutoTest.getElement(...), we have.

isc.AutoTest.getElement('scLocator=//autoID[Class=Window||index=181||length=309||classIndex=1||classLength=2||roleIndex=1||roleLength=2||title=Windows%20Task%20Details%3A%20Ping||scRole=dialog]/item[0][Class="SectionStack"]/section[Class=SectionHeader||index=0||length=1||classIndex=0||classLength=1||roleIndex=0||roleLength=1||scRole=tab||name=isc_OpswisePanelDetailsSection_2]/item[Class=VLayout||index=0||length=1||classIndex=0||classLength=1]/member[Class=TabSet||index=0||length=1||classIndex=0||classLength=1]/tabPane[title=Windows%20Task||index=0]/member[Class=VLayout||index=0||length=9||classIndex=0||classLength=8]/member[Class=DynamicForm||index=0||length=1||classIndex=0||classLength=1]/item[name=name||title=Task%20Name||value=Ping||index=0||Class=TextItem]/element')

When we evaluate the JavaScript expression, the evaluator returns the expected result.

Evaluator: result of 'isc.AutoTest.getElement('scLocator=//autoID[Class=Window||index=181||length=309||classIndex=1||classLength=2||roleIndex=1||roleLength=2||title=Windows%20Task%20Details%3A%20Ping||scRole=dialog]/item[0...' (2ms):
INPUT{name:name}{autocomplete: "off", form: [FORMElement]{name:[object HTMLInputElement]}, height: 14, maxLength: -1, size: 20, type: "text", value: "Ping", valueAsNumber: NaN, width: 296, willValidate: true, validity: [object ValidityState], selectionEnd: 4, selectionDirection: "forward", controllers: [object XULControllers], textLength: 4, dataset: [object DOMStringMap], properties: [object HTMLPropertiesCollection], tabIndex: 3870, spellcheck: true, style: [object CSS2Properties], className: "opswiseTextItem", offsetParent: [TDElement]{ID:isc_ML}, offsetTop: 2, offsetLeft: 2, offsetWidth: 302, offsetHeight: 22, tagName: "INPUT", id: "isc_MJ", classList: opswiseTextItem, attributes: [object MozNamedAttrMap], children: [object HTMLCollection], scrollWidth: 300, scrollHeight: 20, clientTop: 1, clientLeft: 1, clientWidth: 300, clientHeight: 20, outerHTML: "<input name="name" id="isc_MJ" handlenat..."[382], nodeType: 1, nodeName: "INPUT", baseURI: "http://127.0.0.1:7081/opswise/", ownerDocument: [object HTMLDocument], parentNode: [TDElement]{ID:isc_ML}, parentElement: [TDElement]{ID:isc_ML}, childNodes: [object NodeList], namespaceURI: "http://www.w3.org/1999/xhtml", localName: "input", }

However, if we have a situation where the "name" strategy cannot match, we expected it to fallback to the next strategy, as per the documentation.

https://www.smartclient.com/smartcli...ocatorStrategy
https://www.smartclient.com/smartcli...orTypeStrategy

By default we use the following strategies in order to identify a component from a list of candidates:
name: Does not apply in all cases but in cases where a specified name attribute has meaning we will use it - for example for sections in a section stack.
title: If a title is specified for the component this may be used as a legitimate identifier if it is unique within the component - for example differently titled tabs within a tabset.
index: Locating by index is typically less robust than by name or title as it is likely to be affected by layout changes on the page.
If an explicit strategy is specified, that will be used to locate the component if possible. If no matching component is found using that strategy, we will continue to try the remaining strategies in order as described above.

For example, if you take the above scLocator, and modify the following fragment.

item[name=name||title=Task%20Name||value=Ping||index=0||Class=TextItem]

To:

item[name=nameNoMatch||title=Task%20Name||value=Ping||index=0||Class=TextItem]

and re-evaluate the JavaScript expression, the result is unexpectedly null.

However, if we remove the name strategy completely from the scLocator, as follows.

item[title=Task%20Name||value=Ping||index=0||Class=TextItem]

and re-evaluate, the evaluator returns the expected match again, which seems to imply it is not continuing on with the title strategy after no match found with the name strategy.

Questions:

1) How come it is not continuing on with the title and index strategies when the name strategy is not a match, as described above?

2) What tool do you use internally for testing the framework?

3) If it is Selenium, are you using IDE+Selenium RC (Selenium 1.0) as described in the user doc or are you using the Webdriver (Selenium 2.0 and 3.0)?

Thanks in advance!

[Isomorphic]

1) How come it is not continuing on with the title and index strategies when the name strategy is not a match, as described above?

A FormItem "name" field is treated much as the Canvas "ID" field in that if it's specified, it's considered definitive, so that upon a mismatch, there is no fallback and the entire locator fails. The idea is that you should only include a FormItem name if you've assigned it manually., much as with a Canvas "ID". As such, it's unlikely to change or disappear, so there should be few situations where a fallback can occur unless some major error has occurred somewhere.

What situation are you encountering where FormItem names disappear?

We do agree that the docs aren't clear on this, and we'll make some adjustments.

2) What tool do you use internally for testing the framework?

We rely on several different types of tests, but one variety makes use of Selenese scripts, similar to what you as a customer can run using the TestRunner tool

.

3) If it is Selenium, are you using IDE+Selenium RC (Selenium 1.0) as described in the user doc or are you using the Webdriver (Selenium 2.0 and 3.0)?

In SGWT 6.1p/SC 11.1p or older, the TestRunner tool uses Selenium v2 APIs and our user extensions to directly execute Selenese. In SGWT 12.0p/SC 12.0p and newer releases, we've switched to Seleneium v3, which no longer supports our user extensions, so the TestRunner tool executes Selenese via a simulation engine called SeleneseRunner that makes calls to our WebDriver wrapper classes, such as SmartClientWebDriver. If you notice some Selenese that won't run in SeleneseRunner, please report it so we can address the problem.

As far as Selenium IDE, that's independent of any specific Selenium JAR and, as an interactive tool, not used by any of our automated processes. Although the original Selenium IDE cannot be installed in Firefox Quantum, you should for now still be able to use it to test Selenese scripts by installing it in Firefox 52 ESR, which is still under support. There is a new version of Selenium IDE under development for Firefox Quantum, but it currently lacks support for both our special locators and Selenium command overrides.

[stonebranch2]

Hi Isomorphic,

Thank you for the follow-up.

What situation are you encountering where FormItem names disappear?

In our case, we were experimenting with the behaviour to better understand the expectations with respect to locator strategies, by specifying a name we knew it couldn't match on. At which point, we couldn't reconcile the behaviour with the documentation. Please do let us know when the documentation adjustments have been made, we'd appreciate that.

Thanks again

[Isomorphic]

We've added clarifying remarks to the documentation for locatorStrategy. This should be in the nightly builds dated 2018-06-19 and beyond.

[stonebranch2]

Hi Isomorphic,

Thank you for the update on the LocatorStrategy documentation.

I would like to follow up on the Automated Testing documentation, specifically, the documentation at the link below.

https://www.smartclient.com/smartcli...tomatedTesting

Do you have any plans to update this documentation?

For example, in the section, WebDriver / "Selenium 2", you note the following:

...we continue to recommend Selenium 1.0 rather than WebDriver-based Selenium 2...

...Ultimately, our current recommendation is to use Selenium 1.0 and Selenium RC exclusively or at least primarily...

Would you say that the WebDriver-based Selenium 2 approach is now a better approach than "Selenium 1.0 and Selenium RC"?

With your move internally to use Seleneium v3 in SGWT 12.0p/SC 12.0p for automated processes, do you foresee this documentation getting a face-lift to touch upon that too?

And, for those using the WebDriver-based Selenium 2 approach, will they have any issues if they upgrade to SGWT 12.0p/SC 12.0p?

Thank you

[Blama]

Hi stonebranch2,

please see this documentation update on Selenium 3. I don't know if it made it to the real docs already, though.

Best regards
Blama

[stonebranch2]

Thank you Blama