Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [swtbot-dev] Identifying and finding widgets for both finder and test recorder

A strong -1 for any widget location based on XPath. I've known selenium[1] developers that supports xpath for recording and playback and this is one hell of a pain to deal with for writing any test scripts.

XPath makes test scripts write-only. There's no way to look at a broken test and figure out what a particular XPath referred to!

Not to mention that implementing XPath or a subset of it on top of swt is lot more work than the recorder itself.

SWTBot internally has some places where you can resolve some constructs like (//Composite[0]/Group[1]/Button[0]) but taking it to the next level (//Composite[0]/Group[text="myGroup"]/Button[text="Ok"]) is a lot of work and a project by itself. I'd recommend you fork the github repo and try it out to see how things go.

--
Ketan
ketan.padegaonkar.name | eclipse.org/swtbot

[1] - http://seleniumhq.org/

On 4/26/10 1:10 AM, Mickael Istria wrote:
Hello all,

I had a few time to think about test recording, and the underlying
problem we discussed with Ketan at EclipseCon: identifying widgets that
are the source of events. As far as I remember, a basic solution would
be to set IDs on widget that SWTBot could resolve, but it requires the
developer to think about putting IDs on widgets while developing the UI,
and it is not a common practice.
Then I thought about a resolver based on XPath-like widget
identification. For example an expression like
bot.find(//Composite[0]/Group[1]/Button[0]) would resolve to the 1st
button of 2nd Group of 1st composite in current shell. I think such a
resolver would be easy to write for both SWTBot finder and Test Recorder
and would provide an easy and powerful solution. Moreover, this is
something people will understand even more naturally with the rise of
XWT (identifying a widget in an XML description with XPath sounds natural).

What do you think about that?
And, once we get this working, we could go ahead with expressions like
//Composite[0]/Group[text="myGroup"]/Button[text="Ok"] that would
provide even more flexibility.

Is there a ControlResolver-like interface already existing with methods:
* Control find(Shell shell, String controlId)
* String generateId(Control control)
which could be used by both finder and resolver?
--

Mickael Istria
R&D Engineer

This message and any attachment (the "message") is intended solely for
the addressees and is confidential. If you receive this message by
mistake, please delete it and notify the sender immediately. Any use not
in accordance with its purpose, any out-spread or disclosure, either as
a whole or partially, is prohibited except with formal approval.
Internet cannot guarantee the integrity of this message, therefore
BonitaSoft will not be liable for the message if modified.



_______________________________________________
swtbot-dev mailing list
swtbot-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/swtbot-dev




Back to the top