On 9/16/10 12:17 AM, Daniel Lucraft wrote:
Hi all,
I have two questions about testing SWT that I hope you can help me with.
I'm not actually using SwtBot yet, though I'd like to. This is because we
already have quite a lot of tests written using the current system and when I
tried to drop in Swtbot just to handle some widget operations there were some
conflicts. That's something I'd like to return to.
Currently we have:
* a separate thread containing a Cucumber test runner
* Cucumber is patched so that each step (every operation and assertion) is
wrapped in a syncExec call
This is working pretty well so far. We have a lot of tests (like this:
http://github.com/redcar/redcar/raw/master/plugins/edit_view/features/undo_and_redo.feature
Each step (each given/when/then) is executed by Cucumber in a syncExec block,
and the implementation of the step is manipulating widgets in the background
and/or making assertions.
(Our step library is a bit adhoc, which is why I'm interested in using swtbot,
but that's for another day)
I've seen a few of your tests, you seem to grab a handle to the widget
you want to test and do operations on it. One option might be to wrap
the swt widget in an swtbot widget and do the operations to simplify
things :)
So the first question is: does this jump out at you as being a bad idea in any
way?
Having a syncExec call for *everything* might become a problem in
certain cases. See http://goo.gl/zpF6 for an explanation on why.
SWTBot takes a slightly different approach to doing this:
* All operations(click, close, typeText) happen in asynExec(for the same
reason mentioned in the FAQ), and there are synch points to detect when
this asyncExec has finished execution.
* All inspection operations(getText, isEnabled, isVisible) happen in
syncExec -- this is because the call has to return a value from the UI
thread.
* Also there are cases when sending just one event might confuse SWT on
certain platforms. An example is sending a mouse-down without a
corresponding mouse-up, and all the events that are triggered in between
(mouse-in, mouse-hover, selection etc.)
Second question:
We have one test I'm writing now (testing Macro functionality) that looks
something like this:
When I start recording a macro
And I do X
And I do Y (*)
And I stop recording a macro
And I run the macro (**)
Then the output is correct
Because this is a macro, step (**) does X and Y again. In fact, the
implementation of, say, X in steps (*) and (**) is making *exactly the same
method calls* on the same widgets.
However the operation X works fine in (*) but doesn't work right in (**). So
the tests fail. This is implemented correctly, manual tests in the editor work
fine.
Remember that each *line* of that test is wrapped in a syncExec. So X and Y are
in two separate syncExec blocks when they are listed separately, but they are
in the same syncExec block when they are run in the macro in (**).
A couple more observations before I leave you with my question (thanks for
reading this far!):
* X is a method on StyledText. I notice that the method works by creating an
Event and sending the event to itself. This clued me in that there is something
'eventy' going on<- this is my rough level of understanding :)
* Step (**) usually fails. However, it will always succeed *if I constantly
move the mouse over the window* while it runs !!!
I imagine that I need to somehow have the event queue flushed after every step,
but nothing I tried works.
Do you have any idea what's going on?
Yup, took me a long while to figure out!
The event queue needs to be flushed and or synched for some reason. See
http://goo.gl/DAWc for one possible implementation that's been working
well for swtbot for a long time now.
--
Ketan
http://ketan.padegaonkar.name | http://eclipse.org/swtbot
_______________________________________________
swtbot-dev mailing list
swtbot-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/swtbot-dev
