swtbot-users

[SWTBot-users] "Background" Execution?

[Phil Q. <phi...@in...>]

Hey all,

A bit of a question about philosophy.  One of the things that really interested 
me when I saw that SWTBot dispatches events directly to the widgets themselves 
(vs. the Display) is the idea that perhaps tests could be run in the 
"background" --- which is to say without requiring keyboard focus or control of 
the mouse.  This is a perk since it means one can run tests while continuing to 
code, check mail, etc.  Is this a desired property?  In practice, I'm seeing 
some things in the implementation (notably how the "active shell" is derived) 
that pull against this idea so I wonder if I was just under a mistaken 
impression.  Anyway, I'm curious if this is a feature that is even on the radar. 
  Do other folks think this would be valuable?  General thoughts?

Thanks!


-phil

Re: [SWTBot-users] "Background" Execution?

[Ketan P. <ket...@gm...>]

+1. I would love to have this background execution feature, in SWTBot. 
In addition to what you mention, it would also allow you to parallelize 
tests, which is a *big* win.

Your assessment of the problem is also correct, the notion of 'active 
shell' is what is keeping SWTBot back. SWTBot always looks up widgets in 
the active shell.

There's two issues in the new feature request that you mention here:
1. maintaining state about the active window.
2. being able to send events using display.post for certain types of 
events and widget.notifyListeners for some other types of listeners.

I do have some ideas about internally maintain some information about 
the active shell:
1. Add a display filter (or listener) that keeps track of the active shell.
2. Have the user *explicitly* declare the active shell whenever the user 
expects the shell to change, e.g. after clicking finish on some dialog.

There could be more to this list.

However the one thing that does get into the way of checking emails 
while running tests is the fact that new swt windows always open up in 
the foreground, and there's no way for SWTBot to open them up in a 
'minimized' state.


Reg being able to send events using display.post and 
widget.notifyListeners, I think something like Simon Stewart's Webdriver 
(http://code.google.com/p/webdriver/) might be of help.

Webdriver is slated to become selenium 2.0, and does a lot of ground 
breaking stuff. It uses specific implementations for a particular os, 
and browser implementation. This allows drivers to do something 
different with each browser/os implementation. I feel this is one way 
that SWTBot could take in order to do stuff across platforms, since that 
is the only other way to go about things.

Here's an implementation for safari on macosx 
http://code.google.com/p/webdriver/source/browse/trunk/safari/src/java/org/openqa/selenium/safari/SafariWebElement.java

public void sendKeys(CharSequence... value) {
     StringBuilder builder = new StringBuilder();
     for (CharSequence seq : value)
         builder.append(seq);

     appleScript.executeJavascript(locator + ".focus()");
     appleScript.executeApplescript(
                     "tell application \"System Events\"\r" +
                     "    keystroke (\"" + builder.toString() + "\")\r" +
                     "end tell");
     appleScript.executeJavascript(locator + ".blur()");
}

And and yet another implementation for ie on windows that goes native 
(http://code.google.com/p/webdriver/source/browse/trunk/jobbie/src/java/org/openqa/selenium/ie/InternetExplorerElement.java)
private native void doSendKeys(String string);

-- Ketan

Phil Quitslund wrote:
> Hey all,
> 
> A bit of a question about philosophy.  One of the things that really interested 
> me when I saw that SWTBot dispatches events directly to the widgets themselves 
> (vs. the Display) is the idea that perhaps tests could be run in the 
> "background" --- which is to say without requiring keyboard focus or control of 
> the mouse.  This is a perk since it means one can run tests while continuing to 
> code, check mail, etc.  Is this a desired property?  In practice, I'm seeing 
> some things in the implementation (notably how the "active shell" is derived) 
> that pull against this idea so I wonder if I was just under a mistaken 
> impression.  Anyway, I'm curious if this is a feature that is even on the radar. 
>   Do other folks think this would be valuable?  General thoughts?
> 
> Thanks!
> 
> 
> -phil
> 
> -------------------------------------------------------------------------
> 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
> SWT...@li...
> https://lists.sourceforge.net/lists/listinfo/swtbot-users
> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
> 

Re: [SWTBot-users] "Background" Execution?

[Phil Q. <phi...@in...>]

Hey Ketan,

 > +1.

Glad you share the interest!

> There's two issues in the new feature request that you mention here:
> 1. maintaining state about the active window.
> 2. being able to send events using display.post for certain types of 
> events and widget.notifyListeners for some other types of listeners.

Do you know offhand which events require special casing?  (And are there tests?)

> I do have some ideas about internally maintain some information about 
> the active shell:
> 1. Add a display filter (or listener) that keeps track of the active shell.
> 2. Have the user *explicitly* declare the active shell whenever the user 
> expects the shell to change, e.g. after clicking finish on some dialog.
> 
> There could be more to this list.

I have some ideas on this too...  Do you have any test cases committed?  If not, 
would you be interested in collaborating on some?

> However the one thing that does get into the way of checking emails 
> while running tests is the fact that new swt windows always open up in 
> the foreground, and there's no way for SWTBot to open them up in a 
> 'minimized' state.

This is an interesting point.  I wonder how this is done and whether we can 
intercept and override this default behavior.  I'll poke around --- ultimately 
this may be a question for the SWT gurus.  (Have you talked to them about this BTW?)

> Reg being able to send events using display.post and 
> widget.notifyListeners, I think something like Simon Stewart's Webdriver 
> (http://code.google.com/p/webdriver/) might be of help.
> 
> Webdriver is slated to become selenium 2.0, and does a lot of ground 
> breaking stuff. It uses specific implementations for a particular os, 
> and browser implementation. This allows drivers to do something 
> different with each browser/os implementation. I feel this is one way 
> that SWTBot could take in order to do stuff across platforms, since that 
> is the only other way to go about things.

+1.  A library of native eclipse drivers would be a great boon.  Is this 
something anyone is actively researching?


Thanks!


-phil

Re: [SWTBot-users] "Background" Execution?

[Ketan P. <ket...@gm...>]

>> There's two issues in the new feature request that you mention here:
>> 1. maintaining state about the active window.
>> 2. being able to send events using display.post for certain types of 
>> events and widget.notifyListeners for some other types of listeners.
> 
> Do you know offhand which events require special casing?  (And are there tests?)

The case of the cursor caret not moving because the generated events not 
being 'real events' is one case in point. Display.post makes an event a 
real event, which is why for e.g. it was possible to tab between 
controls, sending widget.notify would not tab.

The reason for this, I believe is that certain things are handled by the 
windowing system. Tabbing, accessors for menus and controls, using arrow 
keys to navigate through trees and lists are examples of such cases. 
Widget.notifyListeners may not always work for such cases.

>> I do have some ideas about internally maintain some information about 
>> the active shell:
>> 1. Add a display filter (or listener) that keeps track of the active shell.
>> 2. Have the user *explicitly* declare the active shell whenever the user 
>> expects the shell to change, e.g. after clicking finish on some dialog.
>>
>> There could be more to this list.
> 
> I have some ideas on this too...  Do you have any test cases committed?  If not, 
> would you be interested in collaborating on some?

I do not have any code or tests around these, I never got around 
implementing them because it's a problem whose solution I do not know.

Also it's a more fundamental problem: should users have to declare what 
active shell to use ? will that make tests unreadable ? What if some 
users are explicitly doing stuff based on paint events, which may never 
get triggered because the paint never happened? yeah there are a lot of 
people who do that, and that's the only way for e.g. to paint on table 
cells.

I'd be happy to pitch in if you have any concrete ideas that solve this 
problem.

>> However the one thing that does get into the way of checking emails 
>> while running tests is the fact that new swt windows always open up in 
>> the foreground, and there's no way for SWTBot to open them up in a 
>> 'minimized' state.
> 
> This is an interesting point.  I wonder how this is done and whether we can 
> intercept and override this default behavior.  I'll poke around --- ultimately 
> this may be a question for the SWT gurus.  (Have you talked to them about this BTW?)

I would definitely want to make this a bigger conversation and get the 
SWT team involved, but I hear there are more SWT platforms, than there 
are people on the SWT team :( There are still a lot of SWT issues 
pending that I've filed as part of SWTBot(along with patches), which are 
yet to be resolved. I don't particularly see issues being resolved by 
the SWT team unless there's a lot of weight put behind it.

>> Reg being able to send events using display.post and 
>> widget.notifyListeners, I think something like Simon Stewart's Webdriver 
>> (http://code.google.com/p/webdriver/) might be of help.
>>
>> Webdriver is slated to become selenium 2.0, and does a lot of ground 
>> breaking stuff. It uses specific implementations for a particular os, 
>> and browser implementation. This allows drivers to do something 
>> different with each browser/os implementation. I feel this is one way 
>> that SWTBot could take in order to do stuff across platforms, since that 
>> is the only other way to go about things.
> 
> +1.  A library of native eclipse drivers would be a great boon.  Is this 
> something anyone is actively researching?

We had investigated this as part of an alternative to selenium and 
webdriver, and used SWT's OS class to go native, it was dropped in favor 
of webdriver.

However this is easier said than done! I know how this is done in Cocoa, 
using apple script. I also know that this is possible on windows using 
c++ (yuck, I'd hate to write that again) or .NET automation API. There's 
also a project called white(http://codeplex.com/white), by a fellow 
ThoughtWorker, which SWTBot can leverage on windows.

This basically only covers windows, and macosx, and leaves a lot of 
linux users out of the party, since I've not found anything for linuxes. 
I believe some API for accessibility would be the only thing that'd be 
useful here.

And there's still the more exotic OSes like solaris, HPUX, and AIX 
(which, to be honest I don't care about much)

-- Ketan

Re: [SWTBot-users] "Background" Execution?

[Phil Q. <phi...@in...>]

> The case of the cursor caret not moving because the generated events not 
> being 'real events' is one case in point. Display.post makes an event a 
> real event, which is why for e.g. it was possible to tab between 
> controls, sending widget.notify would not tab.
> 
> The reason for this, I believe is that certain things are handled by the 
> windowing system. Tabbing, accessors for menus and controls, using arrow 
> keys to navigate through trees and lists are examples of such cases. 
> Widget.notifyListeners may not always work for such cases.

I suspect you're right about this.  That said, it really seems like we ought to 
be able to capture what the app gets back from the OS and simulate it (albeit at 
the native level).  Of course, this may very well be hard and quite likely 
OS-relative.

>>> I do have some ideas about internally maintain some information about 
>>> the active shell:
>>> 1. Add a display filter (or listener) that keeps track of the active shell.
>>> 2. Have the user *explicitly* declare the active shell whenever the user 
>>> expects the shell to change, e.g. after clicking finish on some dialog.
>>>
>>> There could be more to this list.
>> I have some ideas on this too...  Do you have any test cases committed?  If not, 
>> would you be interested in collaborating on some?
> 
> I do not have any code or tests around these, I never got around 
> implementing them because it's a problem whose solution I do not know.
> 
> Also it's a more fundamental problem: should users have to declare what 
> active shell to use ? will that make tests unreadable ? What if some 
> users are explicitly doing stuff based on paint events, which may never 
> get triggered because the paint never happened? yeah there are a lot of 
> people who do that, and that's the only way for e.g. to paint on table 
> cells.

Right.  This is sticky.  I think we can probably track a virtual active shell 
but I'm less confident about the paint events (having just not thought hard 
enough about it).  Is this fundamentally more tricky than the other kinds of 
events you synthesize?  That is, do you think creating fake paint events is not 
a tenable approach?

> I'd be happy to pitch in if you have any concrete ideas that solve this 
> problem.

As I said, I do think we can track a "virtually" active shell but I'd like to 
drive the spike with some tests.  What's the best way for me to get 
contributions to you?  Do you have a sandbox I can commit into?

>>> However the one thing that does get into the way of checking emails 
>>> while running tests is the fact that new swt windows always open up in 
>>> the foreground, and there's no way for SWTBot to open them up in a 
>>> 'minimized' state.
>> This is an interesting point.  I wonder how this is done and whether we can 
>> intercept and override this default behavior.  I'll poke around --- ultimately 
>> this may be a question for the SWT gurus.  (Have you talked to them about this BTW?)
> 
> I would definitely want to make this a bigger conversation and get the 
> SWT team involved, but I hear there are more SWT platforms, than there 
> are people on the SWT team :( There are still a lot of SWT issues 
> pending that I've filed as part of SWTBot(along with patches), which are 
> yet to be resolved. I don't particularly see issues being resolved by 
> the SWT team unless there's a lot of weight put behind it.

We've all got this problem.  *sigh*  You're probably right that this will be 
considered a bit low on the SWT priority list.  Still, might not hurt to ask. 
Perhaps once the migration to eclipse.org is complete.  Will you be at 
EclipseCon?  I bet if we ply those guys with beer we could engage in a little 
brainstorming.

>>> Reg being able to send events using display.post and 
>>> widget.notifyListeners, I think something like Simon Stewart's Webdriver 
>>> (http://code.google.com/p/webdriver/) might be of help.
>>>
>>> Webdriver is slated to become selenium 2.0, and does a lot of ground 
>>> breaking stuff. It uses specific implementations for a particular os, 
>>> and browser implementation. This allows drivers to do something 
>>> different with each browser/os implementation. I feel this is one way 
>>> that SWTBot could take in order to do stuff across platforms, since that 
>>> is the only other way to go about things.
>> +1.  A library of native eclipse drivers would be a great boon.  Is this 
>> something anyone is actively researching?
> 
> We had investigated this as part of an alternative to selenium and 
> webdriver, and used SWT's OS class to go native, it was dropped in favor 
> of webdriver.
> 
> However this is easier said than done! I know how this is done in Cocoa, 
> using apple script. I also know that this is possible on windows using 
> c++ (yuck, I'd hate to write that again) or .NET automation API. There's 
> also a project called white(http://codeplex.com/white), by a fellow 
> ThoughtWorker, which SWTBot can leverage on windows.
> 
> This basically only covers windows, and macosx, and leaves a lot of 
> linux users out of the party, since I've not found anything for linuxes. 
> I believe some API for accessibility would be the only thing that'd be 
> useful here.

All good points.  I'd be happy if we could get some traction in win32 and 
macosx.  I'm guessing that if we succeed in that we can recruit some linux folks 
to pitch in.


-phil

Re: [SWTBot-users] "Background" Execution?

[Ketan P. <ket...@gm...>]

Phil Quitslund wrote:
> As I said, I do think we can track a "virtually" active shell but I'd like to 
> drive the spike with some tests.  What's the best way for me to get 
> contributions to you?  Do you have a sandbox I can commit into?

There's no sandbox. I suspect you may not really need any of the swtbot 
source code for doing the spikes we're discussing here.

If you sign up at bitbucket.org you can pull in the svn repository from 
https://www.bitbucket.org/ketan/swtbot/ and then follow step 2 onwards 
on 
http://www.selenic.com/mercurial/wiki/index.cgi/SubversionToMercurialHowto 
you'll be able to keep up with the 2.0 branch.

> We've all got this problem.  *sigh*  You're probably right that this will be 
> considered a bit low on the SWT priority list.  Still, might not hurt to ask. 
> Perhaps once the migration to eclipse.org is complete.  Will you be at 
> EclipseCon?  I bet if we ply those guys with beer we could engage in a little 
> brainstorming.

I'm myself awaiting for this, my travel to eclipsecon would depend on 
whether my talk is accepted.

> All good points.  I'd be happy if we could get some traction in win32 and 
> macosx.  I'm guessing that if we succeed in that we can recruit some linux folks 
> to pitch in.

Let's see how your spikes would progress and we could target the native 
stuff for a 2.1/2.2 timeframe. For now I'm just putting my head and 
getting 2.0 out the door.

-- Ketan

Re: [SWTBot-users] "Background" Execution?

[Ketan P. <ket...@gm...>]

+1. I would love to have this background execution feature, in SWTBot.
In addition to what you mention, it would also allow you to parallelize
tests, which is a *big* win.

Your assessment of the problem is also correct, the notion of 'active
shell' is what is keeping SWTBot back. SWTBot always looks up widgets in
the active shell.

There's two issues in the new feature request that you mention here:
1. maintaining state about the active window.
2. being able to send events using display.post for certain types of
events and widget.notifyListeners for some other types of listeners.

I do have some ideas about internally maintain some information about
the active shell:
1. Add a display filter (or listener) that keeps track of the active shell.
2. Have the user *explicitly* declare the active shell whenever the user
expects the shell to change, e.g. after clicking finish on some dialog.

There could be more to this list.

However the one thing that does get into the way of checking emails
while running tests is the fact that new swt windows always open up in
the foreground, and there's no way for SWTBot to open them up in a
'minimized' state.


Reg being able to send events using display.post and
widget.notifyListeners, I think something like Simon Stewart's Webdriver
(http://code.google.com/p/webdriver/) might be of help.

Webdriver is slated to become selenium 2.0, and does a lot of ground
breaking stuff. It uses specific implementations for a particular os,
and browser implementation. This allows drivers to do something
different with each browser/os implementation.

Here's an implementation for safari on macosx
http://code.google.com/p/webdriver/source/browse/trunk/safari/src/java/org/openqa/selenium/safari/SafariWebElement.java

public void sendKeys(CharSequence... value) {
     StringBuilder builder = new StringBuilder();
     for (CharSequence seq : value)
         builder.append(seq);

     appleScript.executeJavascript(locator + ".focus()");
     appleScript.executeApplescript(
                     "tell application \"System Events\"\r" +
                     "    keystroke (\"" + builder.toString() + "\")\r" +
                     "end tell");
     appleScript.executeJavascript(locator + ".blur()");
}

And and yet another implementation for ie on windows that goes native
(http://code.google.com/p/webdriver/source/browse/trunk/jobbie/src/java/org/openqa/selenium/ie/InternetExplorerElement.java)
private native void doSendKeys(String string);

The

-- Ketan

Phil Quitslund wrote:
> Hey all,
> 
> A bit of a question about philosophy.  One of the things that really interested 
> me when I saw that SWTBot dispatches events directly to the widgets themselves 
> (vs. the Display) is the idea that perhaps tests could be run in the 
> "background" --- which is to say without requiring keyboard focus or control of 
> the mouse.  This is a perk since it means one can run tests while continuing to 
> code, check mail, etc.  Is this a desired property?  In practice, I'm seeing 
> some things in the implementation (notably how the "active shell" is derived) 
> that pull against this idea so I wonder if I was just under a mistaken 
> impression.  Anyway, I'm curious if this is a feature that is even on the radar. 
>   Do other folks think this would be valuable?  General thoughts?
> 
> Thanks!
> 
> 
> -phil
> 
> -------------------------------------------------------------------------
> 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
> SWT...@li...
> https://lists.sourceforge.net/lists/listinfo/swtbot-users
> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
>