My Developers just gave me the first build of an iOS app that was built with Xcode 8 (8.2.1 to be exact). To my surprise, my Appium scripts are working on my iPhone 6 running iOS 9.3. I thought I’ve read on this forum that if you build the app with XCode 8.x, the ‘old’ locator strategies won’t work, and the Appium Server 1.6.x is required along with the new locator strategies.
I definitely need to move my devices to iOS 10 soon, but if I keep my phone on iOS 9.x, should my current iOS scripts continue to work with Appium Server 1.5.3, even though the app was built with Xcode 8.x?
Just a few quick things to check, il get the details when I’m back at my desktop… Has the web driver agent application been installed onto the device? Does it flash up just before your tests run?
The console will tell you which route is been used but I’m on the mobile at the moment and can’t grab the output, il update this post with more details when I can.
Yes, it shouldn’t matter which version of xcode the developers built the app with when it comes to Appium. It matters what version of xocode you have installed on the machine where you’re running Appium, and the version of iOS on your device/simulator. My app under test was built with xocde 8 also, but I still have XCode 7.3 with Appium 1.5.3 on my test machine, so my scripts still work just fine when I run against my iOS 9.3 iPad and iPhone simulators.
I have tried facebook webdriver agent Inspector, but it is showing blank page. Can any one suggest me how to Inspect element using webdriver agent Inspector in detail ?
So this is not a complaint but has anyone realised that the Facebook web driver agent is a lot faster than the previous method, pre 1.6.0.
I have just seen multiple cases where test’s have failed because there trying to get the page source too quick, break pointing the test’s so they wait between resolves the issue, but I can’t go around adding wait’s between test’s that wouldn’t be good at all.
I wonder if this has changed, I would have thought that the command would report back before moving onto the next…
UPDATE:
This was a result of the page source been grabbed too quickly whilst the animation between views was still occurring. We create an object for the tableView and store it in the scenarioContext, but it was grabbing the previous table, a simple wait for half a second resolves the issue but a better soloution will be needed.
An update on the following issue that may be related to the WDA ,
Specific Error message logged in Appium console:
Enqueue Failure: UI Testing Failure - Failure fetching attributes for element <XCAccessibilityElement: 0x61000065f8f0> Device element: Error Domain=XCTestManagerErrorDomain Code=13 “Error copying attributes -25202”
There are also a few bug reports logged to Apple, that state there are multiple causes to this and that anyone receiving this should also log a bug report.
I have found that in some cases the device is returning the element but the specific element is not yet visible on screen, this could be caused by animations during transition. In my particular case a row is returned and the test click’s on the row but instead of the expected behaviour the ‘Enqueue Failure’ error is returned causing any further test’s to fail.
I have decided to put a dirty hack in and wait for 2 seconds before clicking an element just so I can run all the test’s over night.
This is not a fix, and I will certainly be looking at alternatives, but at least I’m getting closer to the root cause.
waited for the WDA to launch and then exited. Never did any button pressing etc, just literally launched WDA, waited till it showed up and then exited.
6 or 7 iterations later the hung black screen.
Not sure how waiting 2 seconds would help in my case
Ken
Yeah doesn’t look to be the same issue, in some of the post’s on the Apple developer forums an Apple employee mentioned some of the issues where fixed in the version of iOS 10.1 to be exact. If these are related to the OS and possibly accessibility, I can’t rely on waiting for Apple to fix the issues.
Update: Found the issue that’s causing this, it’s already Open on the WDA github with a possible workaround.
The potential workaround for myself that looks to have worked is to change the following method in XCUIElement+FBIsVisible.m.