This site is in read only mode. Please continue to browse, but replying, likes, and other actions are disabled for now.
May 2018
1 / 11
May 2018
May 2018
Markaleth
May '18

Hello,

Recently switched to Appium 1.8.0 from 1.7.2 and i’m seeing a 6x increase in test time on real iOS devices (haven’t checked on sims).

Test code has remained constant throughout the switch with absolutely no changes to code, identifiers, validators or anything else in the test suites or page objects.

Has anyone else been experiencing any significant increase in test times with Appium 1.8.0?

I’m sorry if this is a repost, I haven’t been able to find any other topics pointing to this particular scenario.

Cheers!

  • created

    May '18

  • last reply

    May '18
  • 10

    replies

  • 867

    views

  • 5

    users

  • 1

    like

  • 1

    link

MrZigaS
May '18

I did have the same problem with Appium 1.8.0 when I updated from Java client 4.1.2 to 5.0.4.
I fixed the slowness by updating Java client to 6.0.0-BETA.

alangithubtrader
May '18

In my general experience, iOS test execution time has been much (3x) slower compared to Android. When will Appium be able to address this? I remember back in the days when Apple still used UIAutomator we could hack the plist file to by pass the 1 second delay and test ran super quick. I wonder if there’s such work around for XCUITest?

Smitty
May '18
MrZigaS

@MrZigaS
You just saved my life over here. We had to move to Appium 1.8.0 after the XCode 9.3 update and my scripts on iOS became glacier-like in speed. I was also running Java Client 5.0.4 but have now updated to 6.0.0-BETA5 (which required an update to selenium-java: 3.9.1). Before this update, one of my scripts running against an iPad Air took 66 minutes to complete. The same script after the update just took 5.5 minutes to run. It is still true that the Androids run faster in all cases but I am super happy that iOS devices take twice as long to complete instead of 20 times as long.

Thanks!

MrZigaS
May '18

I’m glad I could help and also happy with the speed, but still waiting for official release of the client.

bennid
May '18

Unsure of the use / need of it, but I saved a bunch of time using the older Java Client (Unsure if 6.0.0-BETA does it) by extending IOSDriver and caching getSession() calls. Looking at the code, the Java Client was putting session details into EVERY Element returned in findElements() (and making a getSession call to the appium server for each), making upwards of 10s of calls for some views. While each call was only 100ms or so, it still grew out of control. Caching the session details (for right or wrong) saved a LOT of these calls.

In your extended driver just put:

@Override
public Response execute(String driverCommand) {
    if (driverCommand.equals(MobileCommand.GET_SESSION)) {
        if (getSessionResponse != null) {
            return getSessionResponse;
        }
        getSessionResponse = super.execute(driverCommand);
        return getSessionResponse;
    }
    return super.execute(driverCommand);
}
alangithubtrader
May '18

@bennid i never knew you could cache the session details, very interseting. Do you know if there is such caching capability for C# client as well?

MrZigaS
May '18
bennid

Are you using java_client 5.0.4 in this case?
How can you access to GET_SESSION while it’s protected? And what exactly is ‘getSessionResponse’?

Markaleth
May '18

I’m delighted this post generated such insightful discussions and i appreciate all the input so far.

I’ve tried a Java client update but, as i’m sure you’re all familiar, that comes with it’s own challenges ([cough] yeah Touch actions, i’m looking at you!), especially since version 6.0 seems to bring very significant changes to the library.

I’d be very curious to hear more on “session response” topic @bennid. While Appium 1.8 certainly accentuated the problem, i feel iOS Driver to Appium Server communications has always been (at least as far as i’m concerned) sub-par in terms of session management.

Looking forward to reading more of your experiences and resolutions for this little bump in automation.

Thank you kindly once again for all your replies!

bennid
May '18
MrZigaS

Ah HA! I put the new CacheIOSDriver in the package io.appium.java_client in order to get to GET_SESSION. getSessionResponse is just a private class level variable I’m using for the “caching” (though it never times out… so I use “caching” loosely.

This was with JavaClient 6.0.0-BETA5, but it would surprise me if it changed between 5.0.4 and 6.0.0.

bennid
May '18
Markaleth

I’ve found it’s more Appium 1.8 that have affected TouchActions than the 6.0.0 client (I do like the Options / builders better than just passing in things… but yes, it was a bit of a change) – though to be fair, having absolute coordinates for both IOS and Android is nice. I also found that creating something of an AppiumHelper as a shim to everything made moving to the newer client easier (so only really changing in one class). I’d love to know from Appium devs if the session details could skew at all, and am I introducing a potential issue by saving it off and re-using it. At the very least it’s speeding up my suite by a few minutes.

Unfortunately I’ve had to back down to appium 1.7.2 due to https://github.com/appium/appium/issues/1070321.