Home » Eclipse Projects » GEF » Automatic Tests for Graphical Editors
| Automatic Tests for Graphical Editors [message #84832] |
Mon, 23 June 2003 14:57  |
Eclipse User |
|
|
|
Hi,
I am exploring the possibility implementing at least partial automatic
tests for a GEF-based editor. A tentative approach (with open
questions) is described below. Any tips will be appreciated, as well as
insights on how others are testing their code ...
Youval
The planned approach consisting of the following "layers" of testing:
Model+Commands <-> Files
---------------------------------
Our models are stored in XML files, so it's easy to manually create
models and compare them to the results of API calls (model inspection
and model modification through commands).
Models -> Figures
-------------------------------------------------------
Again, not difficult to open a file and then validate the generated
Figure hierarchy. It would also be useful to capture an image of the
result and use it for regression tests - but it's not clear how to do it
(see open issues below).
Requests -> Commands, Figures & Files
------------------------------------------------------------ ---------
Once an Editor and its EditPart hierarchy are instantiated, we can
simulate requests and verify that commands are generated correctly, that
the figure hierarchy is updated correctly, and that (after save) the
files are updated correctly.
Gestures (e.g. drag and drop) -> Requests
------------------------------------------------------------ --------
It would be useful to make sure that user gestures are translated into
the correct requests. This seems to be harder, and out of scope at
present, as it probably requires direct intervention with the operating
system's event queue.
Open Issues:
Displaying the editor -
I have been able to programmatically open a GEF editor, and interact
with its EditParts, Models and Figures, but nothing is displayed on the
screen until the end of the test. This is a pity as it would be very
nice to see what's going on while the test is running. I've tried
viewport.getUpdateManager().performUpdate() to no avail - it appears
that the actual painting of the window happens "asynchronously" (through
the handling of multiple OS events). Any ideas how to force a
synchronous repaint?
Capturing the actually painted images -
Would GC.copyArea() work? If so, probably only after the previous issue
is resolved.
Controlling the actual size of the viewport -
This is important when testing sizes and positions of Figures. One way
to do it is to set the size of the OS window (shell.setBounds()), and
have the perspective restored to its defaults. Any better ideas?
|
|
|
| Re: Automatic Tests for Graphical Editors [message #85008 is a reply to message #84832] |
Tue, 24 June 2003 14:58  |
| Eclipse User |
|
|
|
A few answers added below:
Youval wrote:
> Hi,
>
> I am exploring the possibility implementing at least partial automatic
> tests for a GEF-based editor. A tentative approach (with open
> questions) is described below. Any tips will be appreciated, as well as
> insights on how others are testing their code ...
>
> Youval
>
> The planned approach consisting of the following "layers" of testing:
>
>
> Model+Commands <-> Files
> ---------------------------------
> Our models are stored in XML files, so it's easy to manually create
> models and compare them to the results of API calls (model inspection
> and model modification through commands).
>
> Models -> Figures
> -------------------------------------------------------
> Again, not difficult to open a file and then validate the generated
> Figure hierarchy. It would also be useful to capture an image of the
> result and use it for regression tests - but it's not clear how to do it
> (see open issues below).
>
> Requests -> Commands, Figures & Files
> ------------------------------------------------------------ ---------
> Once an Editor and its EditPart hierarchy are instantiated, we can
> simulate requests and verify that commands are generated correctly, that
> the figure hierarchy is updated correctly, and that (after save) the
> files are updated correctly.
>
> Gestures (e.g. drag and drop) -> Requests
> ------------------------------------------------------------ --------
> It would be useful to make sure that user gestures are translated into
> the correct requests. This seems to be harder, and out of scope at
> present, as it probably requires direct intervention with the operating
> system's event queue.
>
>
> Open Issues:
>
> Displaying the editor -
>
> I have been able to programmatically open a GEF editor, and interact
> with its EditParts, Models and Figures, but nothing is displayed on the
> screen until the end of the test. This is a pity as it would be very
> nice to see what's going on while the test is running. I've tried
> viewport.getUpdateManager().performUpdate() to no avail - it appears
> that the actual painting of the window happens "asynchronously" (through
> the handling of multiple OS events). Any ideas how to force a
> synchronous repaint?
The following works: If the test scenario is in a background thread,
with individual chunks invoked using Display#synchExec(Runnable), then a
repaint happens after each chunk.
> Capturing the actually painted images -
>
> Would GC.copyArea() work? If so, probably only after the previous issue
> is resolved.
It does work. Copying the area of the GraphicalViewer's control
produces nice images. It does depend on a full repaint (see previous
issue).
>
> Controlling the actual size of the viewport -
>
> This is important when testing sizes and positions of Figures. One way
> to do it is to set the size of the OS window (shell.setBounds()), and
> have the perspective restored to its defaults. Any better ideas?
>
|
|
|
| Re: Automatic Tests for Graphical Editors [message #85174 is a reply to message #84832] |
Wed, 25 June 2003 10:16 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> I am exploring the possibility implementing at least partial automatic
> tests for a GEF-based editor. A tentative approach (with open
> questions) is described below. Any tips will be appreciated, as well as
> insights on how others are testing their code ...
>
> Youval
>
> The planned approach consisting of the following "layers" of testing:
>
>
> Model+Commands <-> Files
> ---------------------------------
> Our models are stored in XML files, so it's easy to manually create
> models and compare them to the results of API calls (model inspection
> and model modification through commands).
>
> Models -> Figures
> -------------------------------------------------------
> Again, not difficult to open a file and then validate the generated
> Figure hierarchy. It would also be useful to capture an image of the
> result and use it for regression tests - but it's not clear how to do it
> (see open issues below).
>
> Requests -> Commands, Figures & Files
> ------------------------------------------------------------ ---------
> Once an Editor and its EditPart hierarchy are instantiated, we can
> simulate requests and verify that commands are generated correctly, that
> the figure hierarchy is updated correctly, and that (after save) the
> files are updated correctly.
>
> Gestures (e.g. drag and drop) -> Requests
> ------------------------------------------------------------ --------
> It would be useful to make sure that user gestures are translated into
> the correct requests. This seems to be harder, and out of scope at
> present, as it probably requires direct intervention with the operating
> system's event queue.
RobotJ by Rational does this.
> Open Issues:
>
> Displaying the editor -
>
> I have been able to programmatically open a GEF editor, and interact
> with its EditParts, Models and Figures, but nothing is displayed on the
> screen until the end of the test. This is a pity as it would be very
> nice to see what's going on while the test is running. I've tried
> viewport.getUpdateManager().performUpdate() to no avail - it appears
This works for me. In fact, this is how the palette animates when you open
and close drawers. It moves things and then forces the paint. Are you
calling from the Display thread? If not, you'll probably get invalid thread
access exceptions. See also EditPartViewer#flush(), which does the same
thing.
> that the actual painting of the window happens "asynchronously" (through
> the handling of multiple OS events). Any ideas how to force a
> synchronous repaint?
>
> Capturing the actually painted images -
>
> Would GC.copyArea() work? If so, probably only after the previous issue
> is resolved.
>
> Controlling the actual size of the viewport -
>
> This is important when testing sizes and positions of Figures. One way
> to do it is to set the size of the OS window (shell.setBounds()), and
> have the perspective restored to its defaults. Any better ideas?
>
|
|
|
| Re: Automatic Tests for Graphical Editors [message #85407 is a reply to message #85174] |
Wed, 25 June 2003 18:14 |
| Eclipse User |
|
|
|
Randy Hudson wrote:
>>Gestures (e.g. drag and drop) -> Requests
>> ------------------------------------------------------------ --------
>>It would be useful to make sure that user gestures are translated into
>>the correct requests. This seems to be harder, and out of scope at
>>present, as it probably requires direct intervention with the operating
>>system's event queue.
>
>
> RobotJ by Rational does this.
>
Has it been used on GEF editors? Was the experience positive?
>
>>Open Issues:
>>
>>Displaying the editor -
>>
>>I have been able to programmatically open a GEF editor, and interact
>>with its EditParts, Models and Figures, but nothing is displayed on the
>>screen until the end of the test. This is a pity as it would be very
>>nice to see what's going on while the test is running. I've tried
>>viewport.getUpdateManager().performUpdate() to no avail - it appears
>
>
> This works for me. In fact, this is how the palette animates when you open
> and close drawers. It moves things and then forces the paint. Are you
> calling from the Display thread? If not, you'll probably get invalid thread
> access exceptions. See also EditPartViewer#flush(), which does the same
> thing.
>
I've sucessfully used a work-around (described in my previous post), but
would still like to understand this to make sure I am not messing up.
My code did run on the Display thread. Maybe the reason GEF didn't
paint was that in some performUpdate() was run prematurely ( the code
was run from an external action, and the first thing it did was to
invoke IWorkspacePage#openEditor() - the editor was initially closed ).
|
|
|
Goto Forum:
Current Time: Fri May 09 21:56:37 EDT 2025
Powered by FUDForum. Page generated in 0.06902 seconds |
Home