[platform-swt-dev] swt.Robot?

[Thomas L Roche <tlroche@xxxxxxxxxx>]

Are there plans for providing, or has anyone thought much about how to
provide, an SWT substitute for java.awt.Robot? Why I ask:

I'm writing code-generation wizards in SWT/JFace, and regressing them
manually. As functionality grows, so does tedium, sloth, and error.
Also envy--Swing folks can use a number of GUI test automation
packages (see

http://www.superlinksoftware.com/cgi-bin/jugwiki.pl?TestingGUIs

for an incomplete list), but, since these wrap java.awt.Robot (or else
manipulate the AWT EventQueue directly), I can't use them. This annoys.

Almost 8 months ago the following feature request was made

http://bugs.eclipse.org/bugs/show_bug.cgi?id=15025
>> Summary: implement java.awt.Robot for SWT
>> Reporter: mfaraj@xxxxxxxxxx (Mazen Faraj)
>> Opened: 2002-05-01 14:39

<heavily edited>

>> The quick answer to why this is needed is for automating Eclipse UI
>> testing, not through the usual "recording" software products out
>> there, but through writting Java testcases that actually represent
>> your UI automated test. Picture this, when you run your automated
>> JUnit testcases in Eclipse, you are running these automated UI
>> testcases also. So your JUnit testcases are not only for "backend"
>> or "logic" testing! you are also testing your UI functionality.

UI automation would also be useful for marketing (e.g. code demos),
usability testing, rapid prototyping, etc.

>> THE PROBLEM :(
>> Even though I had a prototype working that used Sun's Robot class
>> to automate Eclipse UI testing, there are gltiches. the
>> java.awt.robot class was designed for AWT classes. I worked around
>> some of the problems with using that class with SWT, as opposed to
>> AWT. but still, things where not working as designed just because
>> of the SWT mix with Robot.

Mike_Wilson@xxxxxxx 2002-05-02 09:20
> I understand the kinds of capabilities you are looking for. There is
> no plan to implement this for R2.0, but we do want to look at
> providing something along these lines at some point.

> The challenge, of course, is doing this in a way which doesn't
> require a lot of extra state to be maintained in the widgets or
> drastic changes in the underlying event model. SWT is so close to
> the o/s that typically platform specific scripting facilities will
> work, and hooking into these is likely the direction we would take
> at the SWT level.

> Another interesting alternative would be to generalize the
> mechanisms already found in Eclipse for invoking commands,
> activating windows, etc. and based on these add "scriptable" u/i
> support to Eclipse. This would allow Eclipse to be driven by a 'bot
> without requiring low-level platform specific hacks in SWT.

Note however that, given the large amount of working tooling built
upon awt.Robot, an workalike, API-compatible substitute would be
Greatly Preferred to scripting.

Is any work ongoing in this direction? Is any work planned?

Alternatively, can anyone sketch a roadmap of how to code something
(for want of another term, call it "swt.Robot") that would allow
SWT/JFace users to be able to use GUI-unit-test packages like Abbot,
JFCUnit, etc? At this stage, handwaving and generalities are
acceptable :-)

TIA, Tom Roche, WSSD Struts Tooling