Home » Eclipse Projects » GEF » Recommendations for JUnit testing GEF plug in
| |
| Re: Recommendations for JUnit testing GEF plug in [message #212319 is a reply to message #212265] |
Tue, 21 March 2006 19:08   |
Eclipse User |
|
|
|
Originally posted by: harsh.ti.com
Testing GEF is similar to testing any other component in Eclipse. It all
depends on how much you want to test. In GEF, the easiest things to test
are non-gui features such as commands interfacing with your model. Also,
you could test by creating a stub palette and internally creating the
components.
Regards,
Harsh
|
|
| |
| Re: Recommendations for JUnit testing GEF plug in [message #213062 is a reply to message #212627] |
Sun, 02 April 2006 13:53 |
| Eclipse User |
|
|
|
Originally posted by: proyslim.gmail.com
Hello.
I also would like to know how to test my GEF Plugin.
so, I'd read a book, contributing to eclipse.
I remember that authurs of that book tested their JUnit Plugin.
but, I haven't applied testing technique to my Plugin yet,
because of difficult to set testing enviroment of plugin.
If you need a example of testing plugin, you should read it.
I wish that you can get what you want.
|
|
|
| Re: Recommendations for JUnit testing GEF plug in [message #213119 is a reply to message #213062] |
Mon, 03 April 2006 10:38 |
 Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Yong Sub wrote:
> Hello.
>
> I also would like to know how to test my GEF Plugin.
> so, I'd read a book, contributing to eclipse.
> I remember that authurs of that book tested their JUnit Plugin.
> but, I haven't applied testing technique to my Plugin yet, because of
> difficult to set testing enviroment of plugin.
>
> If you need a example of testing plugin, you should read it.
> I wish that you can get what you want.
>
Hi,
do they really test a GEF plug in in that book? I found it surprisingly
easy to set up a plug in test and have done so to test the commands
operating on my model, but I am not really sure how to go on with the
things special to GEF and test things like request handling and whether
the right commands are returned from my edit parts/policies. If anybody
has done so already, I'd really appreciate code or even ideas. I am
thinking about injecting fake events into the event queue (if that is
possible) to simulate tool activation and triggering. Or should I
better call some methods I don't know yet but that are designed/suited
for testing? Any ideas anybody?
Regards, Thomas.
|
|
|
| Re: Recommendations for JUnit testing GEF plug in [message #213193 is a reply to message #213119] |
Mon, 03 April 2006 18:13 |
| Eclipse User |
|
|
|
Originally posted by: harsh.ti.com
How I implemented my test cases was by creating dummy requests within the
test case itself. For example, creating a ChangeBoundRequest and filling
in the parameters manually. In addition, I created dummy edit policies
that were required to test Edit Parts.
Harsh
|
|
|
| Re: Recommendations for JUnit testing GEF plug in [message #214589 is a reply to message #211712] |
Wed, 19 April 2006 05:35 |
| Eclipse User |
|
|
|
Originally posted by: irbull.cs.uvic.ca
Hi Thomas,
I have also been giving a lot of thought to this.
I wonder how hard it would be to dump the draw operations to an image
and do a bmp compare. You could code a few operations (create a model,
move a node, add a connection, etc...) and instead of rendering it, dump
it to an image. you could then store the image in the JUnit test. When
you re-run the tests, it would compare the images. If they were
different the test would fail, otherwise the test would pass.
If the tests failed, you could show the two images and ask, do you want
to replace the image?
Do you think two images rendered separately would be the same?
i guess we could also create our own graphics device that dumps the draw
operations, but it would be hard to tell when they are different.
Does anyone have any thoughts on this approach?
- Ian
Thomas Maier wrote:
> Hi all,
>
> are there any recommendations on how to use junit to test a self written
> GEF plug in? Or even better yet, any examples?
>
> I have written tests to test my commands operating on the model. I
> would for instance like to test the editparts/policies responding
> correctly to requests/user actions. What I think I should do is:
> - Run the test as a plug in test.
> - Let the test create a model in the workspace.
> - Let the test load that model, this opens up my editor.
>
> And what next? Should I activate tools in the palette and send fake
> input events to the editor control? Should I somehow get the edit parts
> and ask them to handle requests? Any suggestions, pointers, examples,
> code welcome.
>
> Thanks and regards, Thomas.
|
|
|
| Re: Recommendations for JUnit testing GEF plug in [message #215955 is a reply to message #214589] |
Thu, 11 May 2006 14:48 |
Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Hi Ian,
thanks for sharing your thoughts. I have also thought about comparing
the figures on-screen but that is probably the very last item on my
list, because my figures tend to be rather simple and easy to debug.
Dumping draw operations to an image is quite easy. I have written a plug
in to export diagrams to various formats and redirecting the draw
operations was of course the key to it. So I think your approach should
be doable.
Testing the commands is also quite straightforward. However, I was not
sure how to test request handling and command creation and execution.
Meanwhile I have gone down the road of sending fake events to simulate
user input and see if the right things get done. The tests are all
along the lines of:
- Create a fresh project with a model file.
- Open the model file (opens up my GEF editor).
- Select a tool (fake key event (I have bound the tools to keys)).
- Place/click/drag the mouse (fake mouse event).
- Test whether it worked as expected.
I have written a few test cases and it seems to work. The major pain was
to find out when to call Thread.sleep() and Display.readAndDispatch().
Let's see how far I get with this.
Regards, Thomas.
Ian Bull wrote:
> Hi Thomas,
> I have also been giving a lot of thought to this.
>
> I wonder how hard it would be to dump the draw operations to an image
> and do a bmp compare. You could code a few operations (create a
> model, move a node, add a connection, etc...) and instead of rendering
> it, dump it to an image. you could then store the image in the JUnit
> test. When you re-run the tests, it would compare the images. If
> they were different the test would fail, otherwise the test would pass.
>
> If the tests failed, you could show the two images and ask, do you
> want to replace the image?
>
> Do you think two images rendered separately would be the same?
> i guess we could also create our own graphics device that dumps the
> draw operations, but it would be hard to tell when they are different.
>
> Does anyone have any thoughts on this approach?
>
> - Ian
>
>
> Thomas Maier wrote:
>> Hi all,
>>
>> are there any recommendations on how to use junit to test a self written
>> GEF plug in? Or even better yet, any examples?
>>
>> I have written tests to test my commands operating on the model. I
>> would for instance like to test the editparts/policies responding
>> correctly to requests/user actions. What I think I should do is:
>> - Run the test as a plug in test.
>> - Let the test create a model in the workspace.
>> - Let the test load that model, this opens up my editor.
>>
>> And what next? Should I activate tools in the palette and send fake
>> input events to the editor control? Should I somehow get the edit parts
>> and ask them to handle requests? Any suggestions, pointers, examples,
>> code welcome.
>>
>> Thanks and regards, Thomas.
|
|
|
| Re: Recommendations for JUnit testing GEF plug in [message #215976 is a reply to message #215955] |
Thu, 11 May 2006 19:40 |
Holger Oehm
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Hi Thomas,
I would be very interested in two things you mentioned:
1. the plugin for redirecting draw operations (on Linux
it is impossible to print from within eclipse, so
your plugin could help me a lot to circumvent that
particular problem).
2. an example of one of your test cases (your approach looks
to me like the only viable way to test a graphical editor)
I am especially curious about how you create and feed the
fake events into the editor under test.
Could you please post some example coding?
Best Regards,
Holger.
Thomas Maier wrote:
> Hi Ian,
>
> thanks for sharing your thoughts. I have also thought about comparing
> the figures on-screen but that is probably the very last item on my
> list, because my figures tend to be rather simple and easy to debug.
> Dumping draw operations to an image is quite easy. I have written a plug
> in to export diagrams to various formats and redirecting the draw
> operations was of course the key to it. So I think your approach should
> be doable.
>
> Testing the commands is also quite straightforward. However, I was not
> sure how to test request handling and command creation and execution.
> Meanwhile I have gone down the road of sending fake events to simulate
> user input and see if the right things get done. The tests are all
> along the lines of:
>
> - Create a fresh project with a model file.
> - Open the model file (opens up my GEF editor).
> - Select a tool (fake key event (I have bound the tools to keys)).
> - Place/click/drag the mouse (fake mouse event).
> - Test whether it worked as expected.
>
> I have written a few test cases and it seems to work. The major pain was
> to find out when to call Thread.sleep() and Display.readAndDispatch().
> Let's see how far I get with this.
>
> Regards, Thomas.
>
>
> Ian Bull wrote:
>> Hi Thomas,
>> I have also been giving a lot of thought to this.
>>
>> I wonder how hard it would be to dump the draw operations to an image
>> and do a bmp compare. You could code a few operations (create a
>> model, move a node, add a connection, etc...) and instead of rendering
>> it, dump it to an image. you could then store the image in the JUnit
>> test. When you re-run the tests, it would compare the images. If
>> they were different the test would fail, otherwise the test would pass.
>>
>> If the tests failed, you could show the two images and ask, do you
>> want to replace the image?
>>
>> Do you think two images rendered separately would be the same?
>> i guess we could also create our own graphics device that dumps the
>> draw operations, but it would be hard to tell when they are different.
>>
>> Does anyone have any thoughts on this approach?
>>
>> - Ian
>>
>>
>> Thomas Maier wrote:
>>> Hi all,
>>>
>>> are there any recommendations on how to use junit to test a self written
>>> GEF plug in? Or even better yet, any examples?
>>>
>>> I have written tests to test my commands operating on the model. I
>>> would for instance like to test the editparts/policies responding
>>> correctly to requests/user actions. What I think I should do is:
>>> - Run the test as a plug in test.
>>> - Let the test create a model in the workspace.
>>> - Let the test load that model, this opens up my editor.
>>>
>>> And what next? Should I activate tools in the palette and send fake
>>> input events to the editor control? Should I somehow get the edit parts
>>> and ask them to handle requests? Any suggestions, pointers, examples,
>>> code welcome.
>>>
>>> Thanks and regards, Thomas.
--
Holger Oehm <holger.oehm@holger-oehm.de>
KeyID: B50E51A9, 1024bit at http://www.holger-oehm.de/public-key.asc
Fingerprint: E92A 5C2C 497A 44ED 23C0 DB66 1DD9 3EF7 B50E 51A9
|
|
|
| Re: Recommendations for JUnit testing GEF plug in [message #216099 is a reply to message #215976] |
Sun, 14 May 2006 21:42 |
Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Hi Holger,
the plug in I was talking about is at
http://www.se.eecs.uni-kassel.de/~thm/Projects/ImageExport/i ndex.html
It is intended to be a general image exporting plug in being flexible
enough to support various formats (BMP, JPEG, PDF, SVG is what we have
right now). This should at least give you a way to print some stuff.
The code I currently use is appended below. ripped straight out of my
project. It is, well, a bit rough because I am still fiddling around
with it and need some more experience to actually know what's good and
what's not, but it should get you going. Unfortunately, these days I am
loaded with lots of other work. If you have any suggestions how to
improve that stuff, please let me know. There is a base class
UITestCase which defines lots of methods to deal with fake events. And
there is ClassTest, which simulates user input to create a class (the
project is a UML editor).
HTH, Thomas.
/*
* Janus Plugin -- Java'n'UML Simultanously.
*
* Janus Plugin aims to extend Eclipse's Java Environment with UML
editing capabilities.
* Java code and UML diagrams can both be edited and update each other.
*
* Copyright (C) 2003, 2004, 2005, 2006 Thomas Maier, University of
Kassel.
*
* Janus Plugin is free software; you can redistribute it and/or
modify it under the
* terms of the GNU General Public License as published by the Free
Software Foundation;
* either version 2 of the License, or (at your option) any later version.
*
* Janus Plugin is distributed in the hope that it will be useful, but
WITHOUT ANY
* WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A
* PARTICULAR PURPOSE. See the GNU General Public License for more
details.
*
* You should have received a copy of the GNU General Public License
along with this
* program; if not, write to the Free Software Foundation, Inc., 59
Temple Place, Suite
* 330, Boston, MA 02111-1307 USA
*
* Contact Address:
*
* URL: janus-plugin.sourceforge.net
* email: Thomas.Maier@uni-kassel.de
*
* Thomas Maier
* University of Kassel
* Research Group Software Engineering
* Wilhelmshöher Allee 73
* 34121 Kassel
* Germany
*/
package de.unikassel.janus.tests;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import junit.framework.TestCase;
import org.eclipse.core.resources.IFile;
import org.eclipse.core.resources.IProject;
import org.eclipse.core.resources.IWorkspaceRoot;
import org.eclipse.core.resources.ResourcesPlugin;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.gef.GraphicalViewer;
import org.eclipse.gef.ui.palette.PaletteViewer;
import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Point;
import org.eclipse.swt.widgets.Control;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Event;
import org.eclipse.swt.widgets.MessageBox;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.ui.IEditorPart;
import org.eclipse.ui.IPerspectiveDescriptor;
import org.eclipse.ui.IViewReference;
import org.eclipse.ui.IWorkbenchPage;
import org.eclipse.ui.IWorkbenchWindow;
import org.eclipse.ui.PartInitException;
import org.eclipse.ui.PlatformUI;
import org.eclipse.ui.ide.IDE;
import org.eclipse.uml2.Model;
import
de.unikassel.janus.classdiagrams.editor.palette.ClassDiagram EditorPalette;
import de.unikassel.janus.uml2.JanusUML2;
public abstract class UITestCase extends TestCase
{
public static final String OUTLINE_VIEW_ID =
"org.eclipse.ui.views.ContentOutline";
public static final String RESOURCE_PERSPECTIVE_ID=
"org.eclipse.ui.resourcePerspective";
private Display display;
private Shell workbenchShell;
private IWorkbenchWindow workbenchWindow;
@Override
protected void setUp() throws Exception
{
super.setUp();
display = Display.getCurrent();
// Close all perspectives but Resource, close all views, set
workbench window size.
workbenchWindow =
PlatformUI.getWorkbench().getActiveWorkbenchWindow();
workbenchShell = workbenchWindow.getShell();
IWorkbenchPage page = workbenchWindow.getActivePage();
boolean foundPerspective = false;
IPerspectiveDescriptor[] perspectives = page.getOpenPerspectives();
for (int i = 0; i < perspectives.length; i++)
{
IPerspectiveDescriptor perspective = perspectives[i];
if (perspective.getId().equals(RESOURCE_PERSPECTIVE_ID))
{
foundPerspective = true;
}
else
{
page.closePerspective(perspective, false, false);
}
}
if (!foundPerspective)
{
PlatformUI.getWorkbench().showPerspective(RESOURCE_PERSPECTI VE_ID,
workbenchWindow);
}
IViewReference[] views = page.getViewReferences();
for (int i = 0; i < views.length; i++)
{
page.hideView(views[i]);
}
workbenchWindow.getShell().setSize(1000, 800);
}
@Override
protected void tearDown() throws Exception
{
super.tearDown();
}
protected Display getDisplay()
{
return display;
}
protected Shell getWorkbenchShell()
{
return workbenchShell;
}
protected IWorkbenchWindow getWorkbenchWindow()
{
return workbenchWindow;
}
protected IEditorPart openEditor(IFile file) throws PartInitException
{
return IDE.openEditor(getWorkbenchWindow().getActivePage(), file);
}
protected void closeEditor(IEditorPart editor)
{
editor.getEditorSite().getPage().closeEditor(editor, false);
}
protected IProject getOrCreateProject(String projectName) throws
CoreException
{
IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
IProject project = root.getProject(projectName);
if (!project.exists()) { project.create(null); }
if (!project.isOpen()) { project.open(null); }
return project;
}
protected IFile createEmptyFile(String projectName, String fileName)
throws CoreException, IOException
{
Model model = JanusUML2.createModel();
model.setName("emptyDiag");
IProject project = getOrCreateProject(projectName);
IFile file = project.getFile(fileName);
ByteArrayOutputStream outputStream =
JanusUML2.createStream(model, file);
file.create(new
ByteArrayInputStream(outputStream.toByteArray()), false, null);
return file;
}
protected void selectTool(GraphicalViewer graphicalViewer, String
toolID)
{
PaletteViewer paletteViewer =
graphicalViewer.getEditDomain().getPaletteViewer();
ClassDiagramEditorPalette palette = (ClassDiagramEditorPalette)
paletteViewer.getPaletteRoot();
paletteViewer.setActiveTool(palette.getToolEntry(toolID));
}
protected void postDoubleEscape()
{
postKeyEvent(SWT.ESC);
postKeyEvent(SWT.ESC);
readAndDispatchEvents();
}
protected void setCursorLocation(Control control, int x, int y)
{
getDisplay().setCursorLocation(getDisplay().map(control, null,
x, y));
}
protected void postLeftMouseClickEvent()
{
postMouseClickEvent(1);
}
protected void postLeftMouseDragEvent(Control control, int x, int y)
{
postMouseDragEvent(control, 1, x, y);
readAndDispatchEvents();
}
protected void postMouseDragEvent(Control control, int button, int
x, int y)
{
postMouseDownEvent(button);
readAndDispatchEvents();
postMouseMoveEvent(control, x, y);
readAndDispatchEvents();
postMouseUpEvent(1);
readAndDispatchEvents();
}
protected void postMouseClickEvent(int button)
{
postMouseDownEvent(button);
sleep();
postMouseUpEvent(button);
sleep();
readAndDispatchEvents();
}
protected Event postMouseDownEvent(int button)
{
Event event = new Event();
event.type = SWT.MouseDown;
event.button = button;
getDisplay().post(event);
return event;
}
protected Event postMouseUpEvent(int button)
{
Event event = new Event();
event.type = SWT.MouseUp;
event.button = button;
getDisplay().post(event);
return event;
}
protected Event postMouseMoveEvent(Control control, int x, int y)
{
Point point = getDisplay().map(control, null, x, y);
Event event = new Event();
event.type = SWT.MouseMove;
event.x = point.x;
event.y = point.y;
getDisplay().post(event);
/*
* It seems I must not call this here, because things break,
then. I don't know why.
*/
//readAndDispatchEvents();
return event;
}
/* mouse drag:
mouse down: MouseEvent{FigureCanvas {} time=15876882 data=null button=1
stateMask=0 x=137 y=92}
mouse move: MouseEvent{FigureCanvas {} time=15879432 data=null button=0
stateMask=524288 x=138 y=92}
mouse move: MouseEvent{FigureCanvas {} time=15887473 data=null button=0
stateMask=524288 x=139 y=92}
mouse up: MouseEvent{FigureCanvas {} time=15892969 data=null button=1
stateMask=524288 x=139 y=92}
*/
protected void postKeyEvents(String string)
{
for (int i=0; i<string.length(); i++)
{
char character = string.charAt(i);
boolean shift = Character.isUpperCase(character);
character = Character.toLowerCase(character);
if (shift)
{
postKeyDownEvent(SWT.SHIFT);
sleep();
}
postKeyDownEvent(character);
sleep();
postKeyUpEvent(character);
sleep();
if (shift)
{
postKeyUpEvent(SWT.SHIFT);
}
readAndDispatchEvents();
}
}
protected void postKeyEvent(char character)
{
postKeyDownEvent(character);
sleep();
postKeyUpEvent(character);
sleep();
readAndDispatchEvents();
}
protected void sleep()
{
sleep(100);
}
protected void sleep(long millis)
{
try { Thread.sleep(millis); } catch (InterruptedException e) {
/* Empty */ }
}
protected Event postKeyDownEvent(char character)
{
Event event = new Event();
event.type = SWT.KeyDown;
event.character = character;
getDisplay().post(event);
return event;
}
protected Event postKeyUpEvent(char character)
{
Event event = new Event();
event.type = SWT.KeyUp;
event.character = character;
getDisplay().post(event);
return event;
}
protected void postKeyEvent(int keyCode)
{
postKeyDownEvent(keyCode);
sleep();
postKeyUpEvent(keyCode);
sleep();
readAndDispatchEvents();
}
protected Event postKeyDownEvent(int keyCode)
{
Event event = new Event();
event.type = SWT.KeyDown;
event.keyCode = keyCode;
getDisplay().post(event);
return event;
}
protected Event postKeyUpEvent(int keyCode)
{
Event event = new Event();
event.type = SWT.KeyUp;
event.keyCode = keyCode;
getDisplay().post(event);
return event;
}
protected void readAndDispatchEvents()
{
sleep();
//System.err.print("-- events: ");
while (getDisplay().readAndDispatch())
{
//System.err.print(".");
}
//System.err.println();
}
protected void waitUserInput()
{
getDisplay().syncExec(new Runnable() {
public void run()
{
waitForMessageBox();
}
});
}
void waitForMessageBox()
{
final Shell shell = new Shell(getDisplay(), SWT.NO_FOCUS );
shell.setText("Bla Shell");
shell.setLocation(1500, 100);
shell.setSize(50, 50);
shell.open();
while (true)
{
MessageBox box = new MessageBox(shell, SWT.NO_FOCUS | SWT.OK
| SWT.PRIMARY_MODAL);
box.setText("bla");
box.setMessage("Click to continue.");
box.open();
break;
}
shell.close();
}
}
/*
* Janus Plugin -- Java'n'UML Simultanously.
*
* Janus Plugin aims to extend Eclipse's Java Environment with UML
editing capabilities.
* Java code and UML diagrams can both be edited and update each other.
*
* Copyright (C) 2003, 2004, 2005, 2006 Thomas Maier, University of
Kassel.
*
* Janus Plugin is free software; you can redistribute it and/or
modify it under the
* terms of the GNU General Public License as published by the Free
Software Foundation;
* either version 2 of the License, or (at your option) any later version.
*
* Janus Plugin is distributed in the hope that it will be useful, but
WITHOUT ANY
* WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A
* PARTICULAR PURPOSE. See the GNU General Public License for more
details.
*
* You should have received a copy of the GNU General Public License
along with this
* program; if not, write to the Free Software Foundation, Inc., 59
Temple Place, Suite
* 330, Boston, MA 02111-1307 USA
*
* Contact Address:
*
* URL: janus-plugin.sourceforge.net
* email: Thomas.Maier@uni-kassel.de
*
* Thomas Maier
* University of Kassel
* Research Group Software Engineering
* Wilhelmshöher Allee 73
* 34121 Kassel
* Germany
*/
package de.unikassel.janus.tests;
import org.eclipse.core.resources.IFile;
import org.eclipse.draw2d.geometry.Dimension;
import org.eclipse.draw2d.geometry.Point;
import org.eclipse.gef.GraphicalEditPart;
import org.eclipse.gef.GraphicalViewer;
import org.eclipse.ui.IEditorPart;
import org.eclipse.uml2.Model;
import org.eclipse.uml2.Type;
import
de.unikassel.janus.classdiagrams.editor.palette.ClassDiagram EditorPalette;
import de.unikassel.janus.uml2.JanusUML2;
public class ClassTest extends UITestCase
{
private IFile file;
@Override
protected void setUp() throws Exception
{
super.setUp();
file = createEmptyFile("de.unikassel.janus.tests", "ClassTest.uml");
}
public void testCreateMoveResizeClass() throws Exception
{
for (int i=0; i<5; ++i)
{
IEditorPart editorPart = openEditor(file);
Model model = (Model) editorPart.getAdapter(Model.class);
GraphicalViewer graphicalViewer = (GraphicalViewer)
editorPart.getAdapter(GraphicalViewer.class);
assertEquals(0, model.getOwnedTypes().size());
/*
* Is this a GEF bug? It seems the mouse always has to be
moved after activating a tool.
*/
postMouseMoveEvent(graphicalViewer.getControl(), 50, 60);
postLeftMouseClickEvent();
selectTool(graphicalViewer,
ClassDiagramEditorPalette.TOOL_ID_NEW_CLASS);
postMouseMoveEvent(graphicalViewer.getControl(), 70, 80);
readAndDispatchEvents();
postLeftMouseClickEvent();
readAndDispatchEvents();
assertEquals(1, model.getOwnedTypes().size());
Type newClass = model.getOwnedType("NewClass");
assertNotNull(newClass);
assertEquals(new Point(70, 80),
JanusUML2.getLocation(newClass));
postMouseMoveEvent(graphicalViewer.getControl(), 70+10, 80+10);
readAndDispatchEvents();
postLeftMouseDragEvent(graphicalViewer.getControl(),
70+10+50, 80+10+60);
assertEquals(new Point(70+50, 80+60),
JanusUML2.getLocation(newClass));
GraphicalEditPart newClassEditPart = (GraphicalEditPart)
graphicalViewer.getEditPartRegistry().get(newClass);
Dimension size = newClassEditPart.getFigure().getSize();
postMouseMoveEvent(graphicalViewer.getControl(), 120, 140);
readAndDispatchEvents();
postLeftMouseDragEvent(graphicalViewer.getControl(), 120-20,
140-10);
Dimension changedSize = newClassEditPart.getFigure().getSize();
assertEquals(changedSize.width, size.width + 20);
assertEquals(changedSize.height, size.height+ 10);
closeEditor(editorPart);
}
}
}
Holger Oehm wrote:
> Hi Thomas,
>
> I would be very interested in two things you mentioned:
>
> 1. the plugin for redirecting draw operations (on Linux
> it is impossible to print from within eclipse, so
> your plugin could help me a lot to circumvent that
> particular problem).
>
> 2. an example of one of your test cases (your approach looks
> to me like the only viable way to test a graphical editor)
> I am especially curious about how you create and feed the
> fake events into the editor under test.
>
> Could you please post some example coding?
>
> Best Regards,
> Holger.
>
> Thomas Maier wrote:
>
>
>> Hi Ian,
>>
>> thanks for sharing your thoughts. I have also thought about comparing
>> the figures on-screen but that is probably the very last item on my
>> list, because my figures tend to be rather simple and easy to debug.
>> Dumping draw operations to an image is quite easy. I have written a plug
>> in to export diagrams to various formats and redirecting the draw
>> operations was of course the key to it. So I think your approach should
>> be doable.
>>
>> Testing the commands is also quite straightforward. However, I was not
>> sure how to test request handling and command creation and execution.
>> Meanwhile I have gone down the road of sending fake events to simulate
>> user input and see if the right things get done. The tests are all
>> along the lines of:
>>
>> - Create a fresh project with a model file.
>> - Open the model file (opens up my GEF editor).
>> - Select a tool (fake key event (I have bound the tools to keys)).
>> - Place/click/drag the mouse (fake mouse event).
>> - Test whether it worked as expected.
>>
>> I have written a few test cases and it seems to work. The major pain was
>> to find out when to call Thread.sleep() and Display.readAndDispatch().
>> Let's see how far I get with this.
>>
>> Regards, Thomas.
>>
>>
>> Ian Bull wrote:
>>
>>> Hi Thomas,
>>> I have also been giving a lot of thought to this.
>>>
>>> I wonder how hard it would be to dump the draw operations to an image
>>> and do a bmp compare. You could code a few operations (create a
>>> model, move a node, add a connection, etc...) and instead of rendering
>>> it, dump it to an image. you could then store the image in the JUnit
>>> test. When you re-run the tests, it would compare the images. If
>>> they were different the test would fail, otherwise the test would pass.
>>>
>>> If the tests failed, you could show the two images and ask, do you
>>> want to replace the image?
>>>
>>> Do you think two images rendered separately would be the same?
>>> i guess we could also create our own graphics device that dumps the
>>> draw operations, but it would be hard to tell when they are different.
>>>
>>> Does anyone have any thoughts on this approach?
>>>
>>> - Ian
>>>
>>>
>>> Thomas Maier wrote:
>>>
>>>> Hi all,
>>>>
>>>> are there any recommendations on how to use junit to test a self written
>>>> GEF plug in? Or even better yet, any examples?
>>>>
>>>> I have written tests to test my commands operating on the model. I
>>>> would for instance like to test the editparts/policies responding
>>>> correctly to requests/user actions. What I think I should do is:
>>>> - Run the test as a plug in test.
>>>> - Let the test create a model in the workspace.
>>>> - Let the test load that model, this opens up my editor.
>>>>
>>>> And what next? Should I activate tools in the palette and send fake
>>>> input events to the editor control? Should I somehow get the edit parts
>>>> and ask them to handle requests? Any suggestions, pointers, examples,
>>>> code welcome.
>>>>
>>>> Thanks and regards, Thomas.
>>>>
>
>
|
|
|
| Re: Recommendations for JUnit testing GEF plug in [message #216169 is a reply to message #216099] |
Mon, 15 May 2006 18:57 |
Holger Oehm
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Hi Thomas,
many thanks! This looks very promising.
Best regards and thanks a lot,
Holger.
Thomas Maier wrote:
> Hi Holger,
>
> the plug in I was talking about is at
>
> http://www.se.eecs.uni-kassel.de/~thm/Projects/ImageExport/i ndex.html
>
> It is intended to be a general image exporting plug in being flexible
> enough to support various formats (BMP, JPEG, PDF, SVG is what we have
> right now). This should at least give you a way to print some stuff.
>
> The code I currently use is appended below. ripped straight out of my
> project. It is, well, a bit rough because I am still fiddling around
> with it and need some more experience to actually know what's good and
> what's not, but it should get you going. Unfortunately, these days I am
> loaded with lots of other work. If you have any suggestions how to
> improve that stuff, please let me know. There is a base class
> UITestCase which defines lots of methods to deal with fake events. And
> there is ClassTest, which simulates user input to create a class (the
> project is a UML editor).
>
> HTH, Thomas.
>
> [...]
|
|
|
Goto Forum:
Current Time: Fri Apr 19 23:36:26 GMT 2024
Powered by FUDForum. Page generated in 0.04180 seconds |
] 
Search
Help
Register
Login
Home
