Setting IDs in SmartGWT

[pkelley]

I am working on automated GUI testing for SmartGWT. In some of the tests we will need to click on minidaterange items in ListGrid filter editors.

The question is whether or not there is a way to set ids for a minidaterangeitem that appears in a FilterEditor such that when we look in SeleniumIDE we won't get the default id (e.g. isc_MiniDateRangeItem_4).

I have the same question on many different screen elements so hopefully the answer to this will help me with those also.

Thank you in advance for any help on this,
Patrick

[Isomorphic]

Are you using the Selenium extensions we provide ("selenium" directory in the SDK) and have you read the user guide in that directory?

If so then are you complaining about the scLocator? What scLocator are you seeing?

[pkelley]

I didn't mean to sound like I was complaining. I just don't want to rely on any autogenerated ids like the one in the example below if I can help it.

I have read the section and I am using SeleniumIDE with the user extensions you provided. They are a great help.

What I would like to do is be able to do something like setID("myUniqueID") for items like the one listed below so that I don't have autogenerated IDs in my test steps that could change down the road.

Thanks again for the help on this.
Patrick

[pkelley]

Here is an example. In the scLocator below I would like to see an ID I set instead of the autogenerated value for the minidaterangeitem.

scLocator=//DateRangeDialog[ID="[B]isc_MiniDateRangeItem_1[/B]_rangeDialog"]/okButton/

[Isomorphic]

Just a quick note to say - one of our developers is taking a look at this today. In short this looks like something we'll handle at the framework level but we'll let you know what the conclusion is for certain soon.

One question: Which SmartGWT build are you using? Specifically
- which branch (2.5, 3.0, 3.x)?
- is it a nightly build or a release build?
- what's the reported "isc.version"? You can determine this by running "isc.version" in the developer console.

Also - if this is resolved by a framework change, will you be amenable to updating to a newer nightly build to get the change?

[Isomorphic]

An update - we've made a change in the mainline codebase (3.x branch) that should ameliorate this by generating a locator based on the relative path to whatever ancestor-component contains this form item. So if you have an explicit ID specified on a Window (say) which ultimately contains this item the locator should be generated using that window ID rather than relying on the unpredictable generated ID of the MiniDateRangeItem.

[pkelley]

Wow, thank you guys for taking a look at this so quickly.

I believe this solution will be the last missing piece for us for the automated GUI testing we have been working to setup for quite some time.

We are working on the 2.5 branch and are getting far along in our program now. I have looked into it and I do not think upgrading to 3.0 is a possibility at this point for this program. Will these changes be propagated to the 2.5 branch also? We would be happy to use a nightly build version until it makes it into an official 2.5 release.

[Isomorphic]

We should be able to port this across to the 2.5 branch and it will start showing up in the patched nightly builds.
We've assigned an engineer to take a look and will let you know when this is done.

[pkelley]

Which components will see this change? Is this for minidaterangeitems or will this be seen for all of the various form items?
Thank you again for looking into this so quickly!

[Isomorphic]

Well most form items already handle this - for example the locator for a textItem's input element might look like this:
"//SearchForm[ID="findForm"]/item[name=SKU||title=SKU||index=0||Class=TextItem]/element"
You'll notice it's not using the ID of the form item (which might be "TextItem_0" or similar) - it's using the ID of its parent form.

The DateRangeItem is something of a special case that was failing, so we're addressing this one. If you have other cases that seem to be relying on inappropriate auto-generated IDs, feel free to raise them and we'll let you know if they look like things that should be addressed in the framework, vs issues that will have to be resolved by application design.

And in other news - the patch has now been applied to the stable 2.5 and 3.0 branches so will show up in nightly builds there from now on.

Regards
Isomorphic Software