Top 8 Appium Mobile Test Automation Mistakes
Jonathan Lipps, one of the key contributors to the Appium project, has seen a host of mistake testers are making when it comes to Appium automation.
Since Sauce Labs is one of the most prominent 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.
Following are the top 8 Appium blunders that folks make when creating mobile test automation with Appium:
1. Overusing XPath
Appium 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 is preferred because it’s quicker. Keep in mind, however, that semantically accessible IDs are different than IDs in Web pages.
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 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 automation efforts to fail, and that is teams not making their application testable in the first place.
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 up front, development teams should also plan for different testing scenarios and think about how to avoid overlap before diving into Appium 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 app’s elements will solve many of your test automation issues.
4. Not Thinking About Application View States
Another issue Jonathan sees frequently is developers not setting up their applications so that they can get to 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 test 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 test 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 Appium scripts.
When you do this, you’re basically adding 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 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 test code more than the stability of the technology, Appium is a better choice.
There are certain scenarios in which you’ll probably want to use Espresso or XCUIT Test directly.
For example, if your development team is also writing the tests 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 app 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 benefit to you.
The main benefit Appium 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 of Appium 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 Appium’s code where it’s not being as efficient as possible. For the sake of test stability, Appium’s contributors have chosen to use slower strategies in certain instances. Fundamentally, however, Appium 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 Appium’s 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 Appium 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 Appium site before and were disappointed with the docs, check it out again today — Appium.io.