Timeout clicking a UI element with ios-driver about hsac-fitnesse-fixtures HOT 12 CLOSED

I don't know your application or the iOS driver, but a couple of things I can think of:

• Do you get the same exception when using script instead of storyboard with BrowserTest (does taking of screenshots work with the iOS driver)?
• In the message I notice that it is working with an element it found based on its aria-label, is that the same element that your fixture finds based on its name attribute (i.e. does that element also have an aria-label to match its name) or is that a different element
• My fixture tries to determine whether the element is visible before trying to click it. Any chance that causes the problem?

Do you get a stack trace to indicate where exactly in the code the problem is originating? (If not, can you determine that using a debugger, for instance using the FixtureDebug jUnit class included in my baseline installation configured to run your page)?

from hsac-fitnesse-fixtures.

Your fix in #8 did not fix this issue here.

Command duration or timeout: 45 milliseconds
Build info: version: '2.45.0', revision: '5017cb8e7ca8e37638dc3091b2440b90a1d8686f', time: '2015-02-27 09:10:26'
System info: host: 'Marcio-Marchinis-MacBook-Pro-Silver.local', ip: '172.23.70.56', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.10.3', java.version: '1.8.0_40'
Driver info: org.openqa.selenium.remote.RemoteWebDriver
Capabilities [{aut=/Users/mqm/Downloads/ios-driver/InternationalMountains.app, language=en, CFBundleIdentifier=com.yourcompany.InternationalMountains, locale=en_US, variation=iPhone5s, platform=UNIX, rect={size={width=320, height=568}, origin={x=0, y=0}}, elementTree=true, systemName=iPhone OS, browserVersion=1.0, platformVersion=8.3, takesScreenshot=true, browserName=InternationalMountains, javascriptEnabled=true, iosTouchScreen=true, platformName=IOS, rotatable=true, supportedLocales=[en, fr, zh], simulator=true, cssSelectors=true, version=null, CFBundleVersion=1.0, name=iPhone Simulator, locationContextEnabled=true, sdkVersion=8.3, takesElementScreenshot=false, device=iphone, iosSearchContext=true, configurable=true}]
Session ID: 78475ea9-7295-4129-80e2-79eb9c002674
*** Element info: {Using=css selector, value=[aria-label='Mountain 1']}.

The iso-driver comes with an Inspector https://ios-driver.github.io/ios-driver/?page=inspector which is handy to find the elements. There are 2 elements with "Mountain 1" (the menu item and the text label in it) but only 1 has the name "Mountain 1". I will attach a screenshot of the inspector looking at InternationalMountains.

from hsac-fitnesse-fixtures.

Forgot to answer your question: no stack trace / exception. And yes, the iso-driver does take screenshots, here:

from hsac-fitnesse-fixtures.

Here is the menu item:

from hsac-fitnesse-fixtures.

Here is the label inside the menu item:

from hsac-fitnesse-fixtures.

Looking at the exception text I believe the first element with aria-label 'Mountain 1' is being clicked, so it is not a click based on 'name'.

What I read on the ios-driver page its mapping-strategy to define how UIAutomation elements can be found does not match nicely with the heuristic my fixture tries to use to find elements.
The ios-driver puts names, values and labels in linkText or partialLinkText and you have to specify what you are looking for by prefixing name= or value= or label=, or you have to do By.id or By.name or By.className.
I fear my heuristics will not add much value dealing with the 'mapped model' generated. So I believe you will either have to:

• use the low level methods of BrowserTest (e.g. text by xPath, click by xPath or wait for xPath element xpath visible), or
• use include prefixes in the 'place' strings you provide to BrowserTest and/or
• create your own subclass of BrowserTest where you create your own implementation to find a WebElement based on a 'place' supplied (for clicking, typing retrieving text etc)

The heuristics BrowserTest uses are designed for HTML pages, and not for the kind of tree ios-driver creates. So even if they do not throw an error, I don't quite see how they add value for you.

from hsac-fitnesse-fixtures.

The exception might even be an indication that the ios-driver does not support finding by 'css selector', which my heuristic uses. (This is also a problem on some HTML pages with IE 8)

from hsac-fitnesse-fixtures.

Creating your own subclass with a single method to clickByName is quite trivial, if that is what you expect to do. I think that will get you going quite fast

    public boolean clickByName(String name) {
        By by = By.name(name);
        WebElement element = getSeleniumHelper().findElement(by);
        return clickElement(element);
    }

(Of course you could also call this method 'click' and use it as override of BrowserTest's click method.)

from hsac-fitnesse-fixtures.

Maybe you should allow the user to say what method to use? By CSS, by path, by name, by id etc. This is what Xebium does. In my little test fixture I did it with different APIs (https://github.com/sglebs/BetDevFitNesse/blob/master/src/main/java/net/betterdeveloper/fitnesse/RemoteWebDriverFixture.java) - for finding the element and the click API with no parameter assumes "the last element searched for".

BTW, I did not understand what you meant by "use include prefixes in the 'place' strings you provide to BrowserTest and/or". Do you mind explaining it further and/or giving an example? Do you mean this:
| click | name=Mountain 1 |

I can definitely get by with the path-based APIs. Not sure if I will have the same problem when trying selendroid though (same idea as ios-driver, but for Android).

from hsac-fitnesse-fixtures.

The goal of BrowserTest was to have test scripts that read like instructions I would give my mother when explaining what to do. To that end the heuristics are there so that the script does not have to specify technical concepts, but only reference the texts the users sees on the screen.

All methods using xPaths are, of course, a big deviation from that line of thought, so I try to minimize their use, but I find I do need them sometimes.

You understood my 'use prefixes' comment quite right. When I look at the ios-driver documentation it looks like searching by linkText, which is part of my heuristic, in their implementation supports that.

But, if my current 'best guess' is correct and the exception you see is caused by the fact that searching by cssSelector is not supported than all that doesn't matter: that step of the heuristic fails and no further action is taken. I will see whether I can make my heuristic more robust to 'swallow' such an exception and just continue with its next step.

But, like I stated in my previous comment, it looks like the heuristic I built for HTML based pages adds no value for applications when testing with ios-driver. So I believe the best approach would be to make a subclass that overrides the methods to find elements to work on with behavior more suitable to ios-driver.
After my glance through the ios-driver documentation it appears to me the most obvious approach is just to find by name, or id or l10n(), partialLinkText and maybe className.
With that approach you can have the wiki reflect end-user concepts and have the Java code translate this to the webdriver concepts needed. This reflects what my heuristics attempt to do for HTML based applications.
Maybe Selendroid has/requires a different mapping that could also be abstracted away from the wiki. Allowing very similar, or maybe even the same, steps in the wiki.

My goal with FitNesse is readable test scripts, dealing with selectors etc is not something I think belongs there (that's why I don't like Xebium). If I need/want that I'm just as well of writing the integration tests using a unit test framework.

from hsac-fitnesse-fixtures.

I get your point. In fact I tell testers do separate the WHAT from the HOW with scenarios. So, the acceptance criteria reads like plain text just as well. In the HOW (scenario) you see Xebium steps. Or RestFixture steps. Or Soap fixture steps. It works quite well. I call this polymorphic acceptance criteria - I run the same one against the Controller, the Model and the View, just by including different ScenarioLibrary pages with the WHAT->HOW mapping (sub scenarios).

It works quite well.

from hsac-fitnesse-fixtures.

I try to encapsulate the steps with xpaths in them in using scenario's as well. The heuristic is there to remove the need to worry about exactly what it is you need to interact with in the HTML world (e.g. I don't care whether the Comment button on this page is a link a button or an input I want to click it when I'm done).

I just did a bit more digging in the documentation and, as I expected, neither ios-driver or Selendoid support finding by cssSelectors (it makes no sense in the app world) so my heuristic will not work for those drivers. But a BrowserTest subclass not using the heuristic is easy enough to make: just override getElement(String)...

I would appreciate a pull request for a subclass that has a similar heuristic translating end-user concepts to WebElements (dealing with the mapping used by ios-driver (or Selendroid))....
Maybe it can even be integrated by detecting the kind of web driver connected to and choosing the appropriate heuristic accordingly.

from hsac-fitnesse-fixtures.