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.
Read on to learn more about:
- What Appium is
- The top 8 Appium blunders that folks make when creating mobile test automation frameworks
- Additional mobile app testing tips and tricks
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 web apps for Android, iOS, and some other OS 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 mobile app 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.
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.
More TESTGUILD Training Sessions
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 an Android device, 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 mobile 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 are 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 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 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 — Appium.io.
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
- Appium Automation To Infinity and Beyond with Jonathan Lipps
- Appium for Beginners with James Koch
- Dan Cuellar: Creator of Appium – How to Test Mobile Apps
- Automating iOS Apps In the Apple Bubble with Shashikant Jagtap
- Shift Left Mobile Application Testing with Satyajit Malugu
Take Your Appium Automation Testing to the Next Level
For more mobile testing automation awesomeness, tips, and best practices, make sure to check out the upcoming 2023 Automation Guild!
Register for Automation Guild 2023
