I have been running appium 1.6.3 and I was wondering if there was a way to speed up the tests.
I know with the Xcode 7 version there was a hack for making the tests run faster with instruments…but I was wondering if anything similar exists for the xcuitest driver appium tests
Anyone please feel free to reply Thanks!
slowness as in typing into a text field…or getting to a text field in the first place.
the time gape between typing something and sending a button etc. etc…
I’m still facing serious slowness issues with Appium 1.6, though its bit faster than the previous versions. Most of the issues I find are with the Xpaths, so I have replaced all the xpaths with accessibility which has helped a bit.
I haven’t tried IOS Predicate yet. Will give it a try soon. Couple of links below which might be useful -
I also had a lot of cases where I needed to verify the presence of some controls on the screen. Rather than using element.isDisplayed(), I tried getPageSource() and then searched for the elements in this xpath itself. This helped improve the speed at a lot of places.
But it also has added lot of if conditions, because I had common functions for both Android and iOS. So I’m thinking if this is a good approach, or if there is a better way to accomplish this.
This is faster only when we have multiple elements to verify on the same screen. For example, if we use isDisplayed() 5 times, then Appium would internally call getPageSource() all these times.
Rather we can ourselves call getPageSource() once and search for all the elements from that. Time is saved from avoiding calling getPageSource() multiple times.
@anish10110 can you please share method which achieves this ( I didn’t understand how you find element from getPageSource() ) ?
I am using explicit wait for all the elements to be found / not found, didn’t face any slowness. One tip, don’t use Implicit wait at all, just use explicit wait.
@anish10110 that may work for multiple elements but for single element I think pageSource would be slower than a isDisplayed
@VikramVI don’t you face slowness while getting to a text box or typing inside it? or any gap in time between a text field and pressing a, say, Send button?
this means that your screen does not have many elements. And you can use any way of search. On screen with many data (e.g. list of 30 or more elements) predicate faster.
how long takes your average test and how many steps it has?
@Aleksei I may try out the Predicate method to see if it makes a difference for me. Can you please tell me how the following, for e.g., can be converted to a predicate methodology?
@Styris my suggestion was mostly for heavy screen. If your element finding fine by ID you should use this way. But when in list of 30 elements you need to find some element with some text then better use predicate.
@Aleksei I understood your point. The findBy command that I pasted in the last post was because I requested you to paste me an example of how you would write a similar command for finding by predicate?
I would like to revive this thread. Because tests in XCUITest seems much more slower with Real iOS devices.
Between sending the POST and receiving the status 200 response it passes at least around 1 second. Is there anything on XCode/iPhones that we can do to speed up tests. Is there any cap with XCuiTest as there was with UI using instruments?