Selenium IDE Use DynamicForms without IDs

[stefan_berger]

I've tried working with Selenium IDE to test our SmartGWT application. Many of the elements don't have a set ID so the scLocators can be pretty long and not robust for changes in the layout.

For example the following scLocator was generated for a text field in a dynamic form:

scLocator=//Window[ID="FeverchartSearchIncludingAlternativesWindow"]/item[0][Class="VLayout"]/member[Class=HLayout||index=0||length=3||classIndex=0||classLength=3]/member[Class=DynamicForm||index=0||length=2||classIndex=0||classLength=1]/item[name=searchTextItem||title=Suchtext||index=0||Class=TextItem]/element

Notice how the selector contains tons of HLayouts and VLayouts. I tried reducing it to

scLocator=//DynamicForm/item[name=searchTextItem||title=Suchtext||index=0||Class=TextItem]/element

but it doesn't work. No element is found with that selector.

What is the best approach here except for setting an ID?

I've also noticed that using // in the middle of the scLocator doesn't seem to work. Whenever I want to check if a certain type of element is not present I have to use the normal XPath expressions.

The application is running with SmartGWT 4.1 and so are the user-extensions.js and user-extensions-ide.js.

[Isomorphic]

It sounds like you've read some of the docs, but you need to read the rest.

Specifically, selectors are designed to be robust against changes in layout, and will use a series of fallback strategies if elements in the scLocator are missing. You've raised a theoretical concern that selectors *might* not be robust without actually testing any particular scenario (and your reduced selector is just broken).

If you'd like to critique specific fallback behaviors, we'd welcome the feedback - but to make your feedback constructive, it would need to involve a selector captured from one example layout from an application, and then showing a new arrangement of the application where it is conceivable that the selector could automatically adapt, but it doesn't.

[stefan_berger]

I've added a HLayout around the outermost VLayout which broke the selector

scLocator=//Window[ID="FeverchartSearchIncludingAlternativesWindow"]/item[0][Class="HLayout"]/member[Class=VLayout||index=0||length=1||classIndex=0||classLength=1]/member[Class=HLayout||index=0||length=3||classIndex=0||classLength=3]/member[Class=DynamicForm||index=0||length=2||classIndex=0||classLength=1]/item[name=searchTextItem||title=Suchtext||index=0||Class=TextItem]/element

That's why I wanted to remove the first part of the locator so HLayouts and VLayouts don't matter.

and your reduced selector is just broken

What exactly is broken? Do scLocators have to start with [ID=...]?

[stefan_berger]

Also where can I find the documentation? So far the only thing I've found regarding Selenium and SmartGWT is the "Using Selenium" page.

[Isomorphic]

There are some topological changes we try to handle and some that, by design, we don't. For example, if you were to switch the class of one of the intervening layouts, the locator would continue to work. When you instead add an entirely new layout, and there are no IDs assigned to any component nearer to the target, this is a case where you could be introducing another form in a similar overall position. A locator that just finds the first form anywhere in a nested series of layouts is very likely to misfire as the application evolves, especially as forms are used as internal details of many different component types (ListGrid, FilterBuilder, etc).

For this situation we really would recommend setting an ID. If you think that's a bad idea, try to articulate why, and an alternative solution (one that does not involve overly permissive locators).

Yes, your locator is wrong because there is no ID and, by design, we do not have a behavior that searches the whole application to find the first form.

The "Using Selenium" doc is part of a series of interlinked docs on Automated Testing. Be sure to follow the links to read all the material.