On 07-Aug-08, at 8:26 PM, Stefan Seelmann wrote:
> --------------------------------------------
> UIThreadRunnable.asyncExec( bot.getDisplay(), new
> UIThreadRunnable.VoidResult()
> {
> public void run()
> {
> bot.menu("File").menu("Foo...").click();
> }
> } );
> bot.waitUntil( new DefaultCondition()
> {
> public boolean test() throws Exception
> {
> return bot.shell("Foo title") != null;
> }
> public String getFailureMessage()
> {
> return "No dialog";
> }
> } );
All operations like clicks/selects always happen on a non-ui thread.
The only reason (as far as I've seen) why SWTBot blocks is when it is
itself running on a UI thread, and the dialog starts the event loop.
The solution you've provided while it looks good and works, makes the
code quite unreadable if you end up having a bunch of anonymous
classes. What's bad is that things going wrong in these classes don't
always break the tests at that same point. Tests continue to run for a
few more steps and break when things go wrong on the same thread as
SWTBot is running. From my experience with over 200 test suites that
I've written with SWTBot is that, it's best to avoid asyncExec() in
the test code, if possible.
As the author of SWTBot, I would really be interested in how SWTBot
makes life easier (or difficult) for testing SWT apps.
-- Ketan
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SWTBot-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swtbot-users
http://swtbot.org/ - a functional testing tool for SWT/Eclipse
