|Re: sync after AbstractSWTBot#pressShortcut() ? [message #991455 is a reply to message #991447]
||Wed, 19 December 2012 08:57
| Knut Wannheden
Registered: July 2009
What you describe sounds like much more than I was asking about. It is
really just AbstractSWTBot#pressShortcut() I am concerned about. After
that method has been called (e.g. with 'Ctrl+m' to maximize a view) I
often need to wait until the SWT event thread has processed the event
(i.e. actually maximized the view) until I can continue with the test.
We have had some instability with some of our tests which we suspect may
be due to this fact.
Isn't it for similar reasons that AbstractSWTBot#notify() does exactly
this (i.e. runs a no-op using Display#syncExec()) at the end?
On 12/19/12 9:30 AM, Mickael Istria wrote:
> I think it's an interesting idea.
> You'd like to have a way to invoke SWTBot methods in a synchronous way.
> This would require an important refactoring in SWTBot: methods should
> only create the events or Runnable, and then a processor would run it,
> synchronously or asynchronously depending on a configuration for the bot.
> Feel free to open a bug to request this, and to write some code if you
> have time ;) http://wiki.eclipse.org/SWTBot/Contributing
> SWTBot has a huge TestSuite, so there is no big risk in refactoring. If
> something is broken, we'll most likely notice it.
|Re: sync after AbstractSWTBot#pressShortcut() ? [message #1403915 is a reply to message #1403404]
||Mon, 28 July 2014 14:58
|| Mickael Istria - away until August 14th
Registered: July 2009
Location: Grenoble, France
On 07/23/2014 02:58 PM, Knut Wannheden wrote:|
> Do you think it would make sense to change
> AbstractSWTBot#pressShortcut() as described? If yes, I could look into
> providing a patch for this.
If you need to have a synchronous pressShortcut, then you could provide
a patch for that, granted that the default behaviour is still the same
(asynchronous) one. You could think of a system property, a setting on
the bot or something else to trigger the "synchronous" mode.
Such a contribution would be discussed on the swtbot-dev mailing-list
since it introduces a change in one of the main concepts of SWTBot.
But as long as it's not changing the default behaviour of SWTBot and
it's not making it too much more complex to maintain, it would probably
However, I now believe that the synchronous processing is actually an
anti-pattern. Everything is asynchronous when it comes to UI, there can
be latencies and things like that that make that a synchronous mode
doesn't really scale. That's the reason why SWTBot is totally asynchronous.
In general, it makes more sense that to avoid thinking about whether the
event has been processed or not, because it's a too low-level operation.
You should think more about what you're expecting in terms of usage and
write a good ICondition to pass to the bot.wait method. If you want your
test to be more robust, then invoking bot.wait(ICondition) is IMHO the
good way to keep test focusing on usage scenario, and maps better the
real usage: user action => software reaction.
My job: http://www.jboss.org/tools
My blog: http://mickaelistria.wordpress.com
My Tweets: http://twitter.com/mickaelistria
Powered by FUDForum
. Page generated in 0.01664 seconds