Vijay Aravamudhan 12/24/2002 01:59 AM
> As far as the design goes, I would think that something similar to
> jfcUnit (as far as EventData objects go) and a test helper similar
> to RobotTestHelper. In fact, I am in the process of reviewing the
> jfcUnit architecture to determine whether we can just "plugin" new
> event data objects right into it - those that deal with swt
> components.
If any of the following sounds incorrect to you, please lemme know. If
anything sounds correct, please give me an idea of <where | with what
API> the required functionality <is | should be> implemented, and I'll
look through the code.
2 Provide methods which allow one to fire events on each of the
various UI component classes.
These methods would encapsulate the most common events as they relate
specific component type, for use by the implementation in step 4.
These methods would take an argument of type =
org.eclipse.swt.widgets.Widget, while existing AWT methods take type =
java.awt.Component.
3 Provide a means to find identifiable components of a complete target
GUI.
Interfaces for methods implementing this step would be like the
existing TestHelper.findNamedComponent(...) Implementing this step
in SWT, could be done like
//first
Display display = Display.getCurrent();
//then a list of shells
Shell[] shells = display.getShells();
//then, since Shell is a Composite
Control[] controls = shells[i].getChildren();
//finally if a control is a Composite
Control[] nested_controls = ((Composite)controls[i]).getChildren();
4 Provide a means to translate a high-level (human-meaningful)
intention (e.g. click this button, select the 3rd item in the list)
into the corresponding widget-level action.
For SWTUnit, this would involve
- writing SWT-specific *EventData ctors
If the current architecture is not fully pluggable
- modifying TestHelper "firing code" (e.g. sendKeyAction,
enter*AndLeave) to use them
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mazen Faraj is an IBMer who did some work on SWTizing Robot in mid-02.
He recently posted to java-gui-testing:
Mazen Faraj@IBMCA 01/07/2003 12:31 PM
> True, Robot posts to native OS input queue, the javadocs clearly
> state that.
> But, I updated the Eclipse bug report about some glitches I ran
> into. java.awt.Robot can not be used as is with SWT widgets.
> At least this was my experience, maybe there was something I was
> missing at the times (this was more than a year ago! :) ).
> Long story short, I had to pass AWT constants to the Robot apis. SWT
> did not like that. Some worked, others didn't. The
> waitForIdleMethod() certianly did not work.
> and this is why I opened the bug report to get the ball rolling. The
> real work I did at the time was layering an IRobot interface over
> the java Robot class that was more Eclipse specific (check some of
> the code snippets in feature). So for example instead of a low level
> action like keyPress() you had openPerspective() or detachView().
> This is needed for making writing testcases easier and consistent.
The discussion continues on the feature-request page:
> The only dependency Robot has on AWT is the waitForIdle function,
> which posts a Runnable to the AWT event queue and waits for it to
> get run (which isn't really a wait for idle, BTW, but rather a "wait
> for the current end of queue").
> You probably don't want to depend on the robot's autoWaitForIdle
> anyway, so you just need a waitForIdle equivalent for SWT.
> Other than that, I'm not sure what glitches you might be talking
> about since you don't indicate what specific problems you had with
> Robot.
> Unfortunately I have to answer this from memory!! :( I was looking
> for my code and the only code I have left is what I have posted
> here! The problems I had were, like you said, with
> Robot.waitForIdle() and also with Robot.keyPress() and keyRelease().
> I had to use awt constants (like you see in the sample below)
> instead of SWT constants to generate the right event in the native
> OS input queue. and not only that, I could have sworn that not all
> awt constants would work with SWT, ie: the ket would not be pressed.
> For example, to simulate pressing F1 I had to use:
> robot.keyPress(java.awt.event.KeyEvent.VK_F1); which actually
> worked, butr confusing to say the least to an SWT developer. Others
> constants would simply not work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This includes static methods for both SWT and Swing, that find the
widgets (Component's in Swing, Control's in SWT) in a given container
and return a Hashtable of names (Strings) into widgets. This action
can be recursive, if any of the widgets are themselves containers, and
if you call for recursion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Vijay Aravamudhan 12/24/2002 01:59 AM
> As far as the design goes, I would think that something similar to
> jfcUnit (as far as EventData objects go) and a test helper similar
> to RobotTestHelper. In fact, I am in the process of reviewing the
> jfcUnit architecture to determine whether we can just "plugin" new
> event data objects right into it - those that deal with swt
> components.
If any of the following sounds incorrect to you, please lemme know. If
anything sounds correct, please give me an idea of <where | with what
API> the required functionality <is | should be> implemented, and I'll
look through the code.
Note that the following is edited from
http://groups.yahoo.com/group/java-gui-testing/message/97
Steps toward SWTUnit:
0 java.awt.Robot provides toolkit-independent representations of
gestures, e.g. mouse-<move | down | up | wheel>, key-<down | up>
Presumably done, but Faraj may have uncovered problems: see
http://bugs.eclipse.org/bugs/show_bug.cgi?id=15025
2 Provide methods which allow one to fire events on each of the
various UI component classes.
These methods would encapsulate the most common events as they relate
specific component type, for use by the implementation in step 4.
These methods would take an argument of type =
org.eclipse.swt.widgets.Widget, while existing AWT methods take type =
java.awt.Component.
3 Provide a means to find identifiable components of a complete target
GUI.
Interfaces for methods implementing this step would be like the
existing TestHelper.findNamedComponent(...) Implementing this step
in SWT, could be done like
//first
Display display = Display.getCurrent();
//then a list of shells
Shell[] shells = display.getShells();
//then, since Shell is a Composite
Control[] controls = shells[i].getChildren();
//finally if a control is a Composite
Control[] nested_controls = ((Composite)controls[i]).getChildren();
4 Provide a means to translate a high-level (human-meaningful)
intention (e.g. click this button, select the 3rd item in the list)
into the corresponding widget-level action.
For SWTUnit, this would involve
- writing SWT-specific *EventData ctors
If the current architecture is not fully pluggable
- modifying TestHelper "firing code" (e.g. sendKeyAction,
enter*AndLeave) to use them
> 0
OK, let's number that "1" (since the next item is "2" :-)
> java.awt.Robot provides toolkit-independent representations of
> gestures, e.g. mouse-<move | down | up | wheel>, key-<down | up>
> Presumably done, but Faraj may have uncovered problems: see
> http://bugs.eclipse.org/bugs/show_bug.cgi?id=15025
Mazen Faraj is an IBMer who did some work on SWTizing Robot in mid-02.
He recently posted to java-gui-testing:
Mazen Faraj@IBMCA 01/07/2003 12:31 PM
> True, Robot posts to native OS input queue, the javadocs clearly
> state that.
> But, I updated the Eclipse bug report about some glitches I ran
> into. java.awt.Robot can not be used as is with SWT widgets.
> At least this was my experience, maybe there was something I was
> missing at the times (this was more than a year ago! :) ).
> Long story short, I had to pass AWT constants to the Robot apis. SWT
> did not like that. Some worked, others didn't. The
> waitForIdleMethod() certianly did not work.
> and this is why I opened the bug report to get the ball rolling. The
> real work I did at the time was layering an IRobot interface over
> the java Robot class that was more Eclipse specific (check some of
> the code snippets in feature). So for example instead of a low level
> action like keyPress() you had openPerspective() or detachView().
> This is needed for making writing testcases easier and consistent.
The discussion continues on the feature-request page:
http://bugs.eclipse.org/bugs/show_bug.cgi?id=15025
> ---- Additional Comment #4 From Timothy Wall 2003-01-07 10:57 ----
> The only dependency Robot has on AWT is the waitForIdle function,
> which posts a Runnable to the AWT event queue and waits for it to
> get run (which isn't really a wait for idle, BTW, but rather a "wait
> for the current end of queue").
> You probably don't want to depend on the robot's autoWaitForIdle
> anyway, so you just need a waitForIdle equivalent for SWT.
> Other than that, I'm not sure what glitches you might be talking
> about since you don't indicate what specific problems you had with
> Robot.
> ---- Additional Comment #5 From Mazen Faraj 2003-01-07 11:29 ----
> Unfortunately I have to answer this from memory!! :( I was looking
> for my code and the only code I have left is what I have posted
> here! The problems I had were, like you said, with
> Robot.waitForIdle() and also with Robot.keyPress() and keyRelease().
> I had to use awt constants (like you see in the sample below)
> instead of SWT constants to generate the right event in the native
> OS input queue. and not only that, I could have sworn that not all
> awt constants would work with SWT, ie: the ket would not be pressed.
> For example, to simulate pressing F1 I had to use:
> robot.keyPress(java.awt.event.KeyEvent.VK_F1); which actually
> worked, butr confusing to say the least to an SWT developer. Others
> constants would simply not work.
Note that j_tulley <j_tulley@yahoo.com> has written
http://groups.yahoo.com/group/java-gui-testing/files/GUITestCaseHelper.java
This includes static methods for both SWT and Swing, that find the
widgets (Component's in Swing, Control's in SWT) in a given container
and return a Hashtable of names (Strings) into widgets. This action
can be recursive, if any of the widgets are themselves containers, and
if you call for recursion.