Hi,
the name bot.tests is maybe a little misleading. In fact the plugin contains all our tests that depend upon a running Eclipse or plugin infrastructure. Maybe that should be separated more clearly…
True UI tests would indeed be real black box tests, on the other hand some things can be triggered more reliably using features and contexts and in most cases it is mostly relevant for us that the achieved effect on the screen is correct. Some of the tests are also rather old and steam from another UI testing framework we used to work with (Lift).
Regarding accessing the GA from GFAbstractShape: so far we only had the need for that in the tests, so we didn’t move that to the framework. Do you see the need to do so?
Regards,
Michael
From: graphiti-dev-bounces@xxxxxxxxxxx [mailto:graphiti-dev-bounces@xxxxxxxxxxx] On Behalf Of Jörg Reichert
Sent: Mittwoch, 7. September 2011 11:16
To: graphiti-dev@xxxxxxxxxxx
Subject: [graphiti-dev] SWTBot Tests best practices
Hi,
I am currently writting some SWT Bot tests and therefore also took a look at the tests provided by org.eclipse.graphiti.bot.tests.
I was surprised, that in most cases the features and contexts (e.g. add feature, add context) were created and used. I would expect UI tests to be black box tests, so using only the visible UI features for creating diagram elements.
http://code.google.com/a/eclipselabs.org/p/spray/source/browse/tests/org.xspray.examples.one.tests/src/org/xspray/examples/one/tests/SimpleUITest.java
I also wonder, why GFAbstractShape does not provide public access to the GraphicsAlgorithm. Is ((GraphicalEditPart) editPart.part()).getModel() the only recommended way to get the Graphiti objects from the found GEF figures?
Regards,
Joerg
