I've been using Abbot for SWT for 3 months and it is quite impressive to be able to execute scenarios in this "simple" way.
However, I am still a bit confused by some failures that occur sometimes during my execution. These failures never occur at the same time/place in my scenario, so it is quite hard to debug/reproduce/describe. Most of the time, this errors are related to menu management : it seems that Abbot tries to use menus as they are not properly displayed. To sum up, I perform all the menu invocations using MenuItemTester.actionSelectMenuItem(menuPath, null, parentShell, delay);
I arbitrary set delay to 100ms, but it seems that when executing on "slow" laptop or overwhelmed CPU, this delay is too short and that successive clicks are "too close" : the first click (let's say on the Eclipse "File" menu) makes the file menu appearing, but the second one (let's say on the "Save" item) occurs before the file menu has properly been displayed. Thus, the MenuItemTester, which uses a watcher to wait for a specific number of "item clicks" just hangs and my scenario fails with a time out...
I didn't find out if displaying a menu uses an async call (but I suspect it) ? It could explain that issue...In this case, would it be possible to set "adaptive" wait condition : change the delay(XXX) ms to something like waitForMenuToBeDisplayed(), maybe based on "waitForIdle()" method... ? Any hints on SWT menu would be greatly appreciated.
Sebastien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Sebastien, thanks a lot for your post.
Before it I used delay about 200 ms, after your post I replace actionDelay(delay) in MenuItemTester.actionClickMenuItemByPathImp(...) on
final Watcher watcher =
(Watcher)watchers.get(watcherIndex);
wait(new Condition() {
public boolean test() {
return (watcher.gotArmEvent());
}
public String toString() {
return "Error"; }
});
The result is - no delays, you wait until menu item got click or fail if it not got click in 30 sec. I test this method, and it work stable on my machine (I run this method about 1000 times).
Can you check, what this method work fine in your tests?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm afraid what you advised me was already performed in the resolveAndClickItem() method, after the "actionClick(item)" statement.
I tried out anyway to add this condition where you were suggesting me, but unfortunately, this didn't fix my problems : I'm still facing unconsistencies while my code executes : sometimes I get "WidgetNotFoundException", sometimes MenuItemTester indeed finds the item but seems not to click on it : the menu hangs up, though the item is "armed" (but not selected), til a timetou occurs...
Let's talk about a concrete case : I would like to select the File>New>Project item in the main menu bar.
The first call to resolveAndClickItem() performs a click on "File", and waits until this item is "armed". I'm afraid it doesn't ensure us that its sub-menu is properly displayed. So when coming again in the resolveAndClickItem() to click on the "New" item, we cannot assume that the file submenu is displayed, so it can lead to what I observe on my machine...
I am very surprised that you performed a thousand tests on menu without problems. Did you use "submenus" (File>New>Project for exmaple) or just "first level" ones (File>Save for example) ?
Must I call OS specific code to check that the menu is actually displayed ? I can't figure out why nobody already reported this issue, as it is a frequent one for my part...I am pretty sure that this problem is more obvious on slower machines.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Sebastien
Yes, I test second level menu (like File->New->Other) and I had some problem which i fixed. In some systems mechanism of clicking MenuItems need to be fixed. This is separate theme, we can discuss it by private e-mail.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've been using Abbot for SWT for 3 months and it is quite impressive to be able to execute scenarios in this "simple" way.
However, I am still a bit confused by some failures that occur sometimes during my execution. These failures never occur at the same time/place in my scenario, so it is quite hard to debug/reproduce/describe. Most of the time, this errors are related to menu management : it seems that Abbot tries to use menus as they are not properly displayed. To sum up, I perform all the menu invocations using MenuItemTester.actionSelectMenuItem(menuPath, null, parentShell, delay);
I arbitrary set delay to 100ms, but it seems that when executing on "slow" laptop or overwhelmed CPU, this delay is too short and that successive clicks are "too close" : the first click (let's say on the Eclipse "File" menu) makes the file menu appearing, but the second one (let's say on the "Save" item) occurs before the file menu has properly been displayed. Thus, the MenuItemTester, which uses a watcher to wait for a specific number of "item clicks" just hangs and my scenario fails with a time out...
I didn't find out if displaying a menu uses an async call (but I suspect it) ? It could explain that issue...In this case, would it be possible to set "adaptive" wait condition : change the delay(XXX) ms to something like waitForMenuToBeDisplayed(), maybe based on "waitForIdle()" method... ? Any hints on SWT menu would be greatly appreciated.
Sebastien
Hi Sebastien, thanks a lot for your post.
Before it I used delay about 200 ms, after your post I replace actionDelay(delay) in MenuItemTester.actionClickMenuItemByPathImp(...) on
final Watcher watcher =
(Watcher)watchers.get(watcherIndex);
wait(new Condition() {
public boolean test() {
return (watcher.gotArmEvent());
}
public String toString() {
return "Error"; }
});
The result is - no delays, you wait until menu item got click or fail if it not got click in 30 sec. I test this method, and it work stable on my machine (I run this method about 1000 times).
Can you check, what this method work fine in your tests?
Hi Ilya, and thank you for your help.
I'm afraid what you advised me was already performed in the resolveAndClickItem() method, after the "actionClick(item)" statement.
I tried out anyway to add this condition where you were suggesting me, but unfortunately, this didn't fix my problems : I'm still facing unconsistencies while my code executes : sometimes I get "WidgetNotFoundException", sometimes MenuItemTester indeed finds the item but seems not to click on it : the menu hangs up, though the item is "armed" (but not selected), til a timetou occurs...
Let's talk about a concrete case : I would like to select the File>New>Project item in the main menu bar.
The first call to resolveAndClickItem() performs a click on "File", and waits until this item is "armed". I'm afraid it doesn't ensure us that its sub-menu is properly displayed. So when coming again in the resolveAndClickItem() to click on the "New" item, we cannot assume that the file submenu is displayed, so it can lead to what I observe on my machine...
I am very surprised that you performed a thousand tests on menu without problems. Did you use "submenus" (File>New>Project for exmaple) or just "first level" ones (File>Save for example) ?
Must I call OS specific code to check that the menu is actually displayed ? I can't figure out why nobody already reported this issue, as it is a frequent one for my part...I am pretty sure that this problem is more obvious on slower machines.
It does seem like there could be a problem in
MenuItemTester.resolveAndClcikItem:
There is a wait(Condition) after clicking, but
nothing before clicking; as you describe.
you might try a Condition before the actionClick
(MenuItem) call, that waits for getEnabled(item).
although, if this works, it seems like the fix
might better go inside a MenuItemTester.actionClick(MenuItem).
Hi, Sebastien
Yes, I test second level menu (like File->New->Other) and I had some problem which i fixed. In some systems mechanism of clicking MenuItems need to be fixed. This is separate theme, we can discuss it by private e-mail.
Thanks a lot. I'm quite sorry not to have thought about this solution. I'll give it a try and let you informed about that issue.
Again thank you