Appium Automation Top 8 Mistakes (Are you making them)?

Automation Testing Published on:
Appium Automation Top 8 Mistakes

Jonathan Lipps, one of the key contributors to the Appium project, has seen a host of mistakes testers are making when it comes to Appium automation.

Since Sauce Labs is one of the most prominent mobile service providers for Appium, Jonathan has access to all sorts of customer data and insights.

As you can imagine, he noticed clear patterns of common mistakes that customers repeatedly make.

The following are the top 8 Appium blunders that folks make when creating mobile test automation frameworks.

Before we take a look at the top 8 Appium mistakes folks make with testing let make sure we are on the same page with  — what is Appium?

What is Appium

Appium is an open-source automation tool used to test mobile, web, and hybrid applications. At its heart, it's a web server that exposes a rest API, and it uses JSON wire protocol to communicate between your script, the Appium server, and real or virtual devices.

Dan Cuellar the original creator of this software describes it as:

“Appium is a cross-platform mobile UI automation framework. It allows you to write and run UI tests for your mobile apps, for Android iOS, and some other OSs, and mobile devices. It lets you write it using the Selenium JSON driver you know and love from web automation.”

What's great about this automated approach is that your test can also be written in many different programming language bindings. Here are the ones currently supported and available.

There is even a windows implementation called WinAppDriver that drives desktop applications.

Top Appium Mobile Automation Mistakes To Avoid

Now here are the top mistakes, automation engineers make when creating Appium webdriver tests.

1. Overusing XPath

Overusing XPath locators is a shared mistake with Selenium webdriver, although it's a bit more egregious error in the Appium world.

XPath is a very powerful way to find elements, but it comes with a pretty big performance cost.

This is due to XML- and XPath-type queries, which are not natively provided by Google and Apple–at least in the way that we’d like them to be.

This forces Appium to make a lot of expensive calls under the hood to support finding elements reliably when using XPath.

So you can use XPath, but there are even better locator strategies you can use–like accessibility IDs.

2. Not Making Use of Accessibility IDs

Using accessibility ID locators for apps testing is preferred because it’s quicker.

Keep in mind, however, that semantically accessible IDs are different than IDs in web apps.

Be careful not to conflate the two.

Accessibility IDs have a purpose apart from testing, so you should be careful not to confuse or ruin the accessibility of your application for the sake of testing.

In most cases, setting accessibility IDs on your elements to make them more testable helps make your mobile app more accessible—as long as you choose accessibility labels that are sensible to the human beings who are using them.

But this uncovers a deeper issue that causes many mobile automation efforts to fail, and that is teams not making their application testable in the first place.

API Testing

3. Not Making Your App Testable

Jonathan and I both agree that testability is critical.

Before one line of code is written for a new feature, the developers should be planning their solution with automation in mind. Developers should ask themselves, “How can I expose a hook or create a unique ID for this element in order to make it more testable?”

Only when an application is built with automation testing in mind right from the beginning will a team be truly successful with test automation.

Besides planning for testability upfront, development teams should also plan for different testing scenarios and think about how to avoid overlap before diving into coding.

The main solution to most automation reliability issues is to have a conversation with your development team.

Asking them to put the right accessibility IDs, labels or unique IDs for your mobile app’s elements will solve many of your test automation issues.

4. Not Thinking About Application View States

Another issue Jonathan sees frequently when you start to automate your mobile software is developers not setting up their applications so that they can get too specific views and user states quickly.

For example, you might have ten different tests of shopping cart functionality for your app, with eight or nine of them all going through the same steps of logging in and finding items to put in the cart.

These types of test duplications are a huge waste of time.

You should have a way to set up an app’s state and immediately start a script in that appropriate state.

This is doubly significant with Appium because mobile emulators and simulators–being as slow as they are–can often take a long time to get to the right point on the test.

Another way to speed up your scenarios is not to query for the visibility of every element.

5. Querying for the Visibility of Every Element

Querying for the visibility of every element that you retrieve will have a big impact on the runtime of your scripts.

When you do this, you're basically adding an extra overhead of calls and time waiting for Appium to do something every time you retrieve an element.

You want to be sure to only use lazily request element attributes, which are important in the context of your test code.

6. Thinking that Using Native Testing Tools is Always Better

Some testers believe that in order to have reliable mobile tests, it’s always best to use the native apps testing tools of their developers: If you’re using Android use Espresso, if you’re using iOS use XCUITest, etc.

However, Jonathan doesn’t believe this is very good advice.

How many times have you seen Apple break things on point releases for unknowable reasons? Or Google releasing a new automation technology every couple of days?

If you're concerned about the stability of your mobile test code more than the stability of the technology, Appium for open source test automation is a better choice.

There are certain mobile testing scenarios in which you’ll probably want to use Espresso or XCUIT Test directly.

For example, if your engineer development team is also writing the scripts and they're most comfortable in the mobile SDK language and they're using the Google or Apple provider to build tools and development environments and they want that tight integration between the tests and the device and sometimes between the test code and the app code itself.

If that's how you roll, then Appium isn't going to provide a lot of benefits to you.

The main benefit it provides is a WebDriver layer on top of whatever the best technology is. It acts as a stable interface to the automation technology du jour.

Since it provides a WebDriver interface, it means you can write test code in any language. You can leverage your Selenium experience as well as leverage a shared codebase with your Selenium tests.

This is a bit more of a natural fit for organizations that are structured to have more test engineers responsible for the automation of the software.

Sure–it’s great for software developers to write both app code and test code. In a perfect world, it would be awesome. But I see it.

In reality, this is not the case on most teams, so Appium is a really powerful tool for them.

The other benefit is its cross-platform nature. So you’ll end up saving a lot of code and architecture by using Appium if you have to test both iOS and Android devices.


7. Blaming Appium for Being “Slow”

Jonathan admits that there probably are probably instances in which Appium is slower and less efficient than it needs to be.

There are undoubtedly places in the code where it’s not being as efficient as possible. For the sake of test stability, many contributors have chosen to use slower strategies in certain instances. Fundamentally, however, it is not slower than the technologies it relies on.

In fact, Appium surreptitiously relies on XCUIT Test and UIAutomator2.

So, if you're using Appium in an inefficient way–relying on XPath, for instance–then Yes. It's will be slower.

It’s actually understandable because at that point Appium has to work pretty hard to figure out how to do what it meant on the underlying automation engine and sometimes that can be very inefficient.

Jonathan has found that in most of the cases in which people have said that Appium is “slow,” there is something that that can be fixed in terms of how they're utilizing the tool.

There are definitely scenarios in which contributors favor stability over speed because unfortunately, the underlying frameworks aren't always stable.

If you were using the vendor frameworks directly, you’d definitely notice some flakiness, but Appium camouflages that flakiness with a little bit of a performance hit as a result, so the tradeoff is that you get a more stable test build.

8. Not Using the Appium Docs

In the past, folks have tried using the Appium documentation only to leave disappointed and never return.

To avoid making that mistake, Jonathan recommends checking out the new docs, because they have released completely redesigned, reorganized and updated docs that are so much better than they were.

You'll find what is essentially an API reference for Appium, which is something that they’ve never had before.

Now every command that it supports–which client libraries, which drivers it supports–are now all documented.

They’ve even worked on adding a bunch of code examples.

So if you've gone to the site before and were disappointed with the docs, check it out again today —

More Mobile Testing Tips

Want even more automation testing tips? Check out my full TestTalks interview with the main developer of the Appium project Jonathan Lipps.

If you haven't already make sure to check it out on GitHub.

Appium Mobile Testing Based Podcast Episodes For More Tips

Take Your Appium Automation Testing to the Next Level

For more mobile testing automation awesomeness, tips, and best practices make sure to check out Jonathan Lipps's upcoming 2019 Automation Guild session on Evolving Appium: Image Recognition and AI for Mobile Testing!

Appium Testing Session

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  1. You’re right. Number 3 is the game changer. Baking in testability is crucial to success with automation of any type (Unit, Integration, UI/Acceptance). The key is selling both development and management on it. Show them how it benefits them personally. I’ve been pushing this for years, building in hooks (opening up API’s) and static identifiers (by Name or ID property for GUI objects). The more reliable and stable you can make your items to interact with the better chance you have of stable automated tests. Once you have testability baked-in to your software the other things become a lot easier.

  2. Well, if the mentioned documentation is meant to be better than the one before, then that one had to be an revolting nightmare.
    Current documentation barely contains the very basics and leave you guessing the correct commands most of the time, with the sample code in the official repository not even working of the bat (several errors). Getting started takes days not hours.

    Now making a list of common mistakes starting with the locator strategy and with checking visibility is somewhat unfair: At a certain point one either gives up on appium or uses whatever just works, without a decent documentation. This is actually the whole point of the argument “it may be slower but stable” that is made as well in the post.

    Something similar with “Accessibility IDs”, “Application Views”, “Making App testable” which is a contradiction to the point about using Appium instead of native, because the ones writing test aren’t the app developers. Yes, exactly why I want(ed) to use appium, but that means I don’t have any means to make the apps more testable (well, not now at least).

    Instead of compiling such a list on behalf of “Jonathan” you should have made him write up a concise manual for some languages. Which could be paid for by SauceLabs as they seem to be the ones actually profiting from this. And then post it on in the documentation.

    Please be aware that I don’t want to discredit the effort put into appium and the features it provides, but from a users perspective I was somewhat compelled to leave a reply on this >2 years old post, because I’m now in for several days (I think 4-5 days, continuing to the weekend) and have barely gotten it to work with android so far (I don’t really look forward to iOS right now…)

    I will probably subscribe to some service like SauceLabs in the end, but that is when I stay with appium.
    I think those services lose a lot of potential customers, that just give up in the end.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
Appium Automation Top 8 Mistakes

Latest Automation Trends: Top 13 Predictions for 2023

Posted on 01/04/2023

Welcome to my annual Latest Automation Trends: Top 13 Predictions for 2023 article. ...

Chrome Selenium Driver in Visual Studio C#

Posted on 12/21/2022

I'm sure you've all heard of Selenium by now. It's a popular tool ...

15 Reasons Why You Should (or shouldn’t) Automate a Test

Posted on 12/20/2022

Just because you can automate tests doesn’t necessarily mean that you should. In ...