Hi Ketan

Thanks for making such a detailed reply!

On 16 Sep 2010, at 21:07, Ketan Padegaonkar wrote:
> 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 :)

Absolutely :)

> Having a syncExec call for *everything* might become a problem in certain 
> cases. See http://goo.gl/zpF6 for an explanation on why.

If I understand that correctly, the problem with using syncExec is that if it 
tries to do something that blocks on the UI thread (dialogs), then syncExec 
will not return so the test-thread will never continue. Is that correct?

If so, yes, and I've got around this by never opening dialogs in tests :). 
(There is a dialog adapter mock instead.)

But the point is that if we were using asyncExec we would be able to test 
(non-native) modal dialogs?

> 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.

Can a "synch point" be as simple as a syncExec following a bunch of asyncExecs? 
(Because they are always executed in order?)

> 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.

Cool, thanks!

... later ...

OK, I've tried two things. First: refactoring the testing logic so that each 
step executes in an async, which is immediately followed by a sync. This gave 
the same problem.

Then I thought that perhaps the problem was that the macro was still running 
entirely within one step (and therefore one async block). So no events could be 
processed between macro steps. So I refactored the macro in testing so that 
each macro action would be executed as an async/empty-sync pair. Still no joy.

Forgetting about tests for a minute, the macro is a command that is run on the 
gui thread, that makes a bunch of calls to methods on StyledText. Now, that 
*works* in normal editor operation. Why does it work? Shouldn't the macro 
command be blocking the thread while it runs invokes the methods? And isn't 
that exactly the same thing that's happening in the testing thread?? 

Why does the macro work when executed as a single command on the main thread, 
but not when executed as a single command on the test thread???

thanks
Dan

PS if you're interested, this commit contains all my stumblings about on the 
problem:
http://github.com/danlucraft/redcar/commit/bc5c01c9709b47fb2470d4943874011170624981




_______________________________________________
swtbot-dev mailing list
swtbot-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/swtbot-dev

Reply via email to