Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [swtbot-dev] Cucumber running SWT tests

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






Back to the top