Conventional Appium Mobile test automation with Java
As technology and functional complexity increases, dev teams are encountering more challenges in using Appium. Functionize offers AI based mobile testing.
For many years now, Appium has been a fairly effective mobile app test automation tool. As technology and functional complexity increases, development teams are encountering more challenges in using Appium.
We explore some of those challenges here. It’s important, however, that our readers understand that it’s unnecessary to continue grappling with the limitations of Appium. At the end of this article, you’ll learn how Functionize is a significant improvement over conventional mobile app test automation.
Let’s begin by noting that a huge advantage with Appium is that its tests can be written in any language that has a Selenium client library. This includes Node.js, Ruby, and Python. Most importantly for mobile developers, Appium tests can be written in Java, and Swift, Objective-C (legacy iOS language).
The primary benefit of Appium is that it provides is a WebDriver layer that rests on top of the current best technology. It functions as a stable interface to popular automation technology. Moreover, this WebDriver interface architecture enables teams to write tests in any language. It’s feasible to leverage Selenium experience and also manage a shared codebase that contains your Selenium tests.
Appium and writing in Java
There are a number of steps to install and perform basic configuration of Appium. On top of that, you’ve got to wrestle with some thorny issues. We’ll get to those later, but let’s look at what it takes to get going with Appium.
Installing Appium
You can install Appium either with NPM or by downloading Appium Desktop—a graphical, desktop-based way to start the Appium server.
To get the desktop app, simply download the latest version of Appium Desktop from the Releases page.
To get Appium, fork and clone it from https://github.com/appium/appium. Then follow the instructions at the bottom of that page. You can get sample code here:
https://github.com/appium/sample-code/tree/master/sample-code/apps
Installation through NPM
Unless you’re using desktop Appium, you’ll need NPM and node.js. To install node.js, either use nvm or brew install node.
NOTE: Be sure that you do not install either Appium or Node as the superuser. If you do, you’re sure to encounter various problems.
The installation itself is quite simple:
npm install -g appium
Typically, Appium is put to use in automating something specific. Mobile testers are, of course, focusing on either an Android or iOS application. Support for test automation of a mobile platform is given by a specific Appium driver. There are many types of drivers which provide various kinds of automation technology. As you might guess, each driver has its own setup requirements. To automate Android application testing using an Appium Android driver, for example, it’s necessary to configure the Android SDK on your system.
To ensure that your system has the proper setup, it’s important to read the driver documentation for the specific mobile platform(s) that you are automating:
Appium in context
Essentially, Appium is an HTTP server. It waits for a client to connect, and the client instructs Appium the type of session to start and which automation actions to execute when the session starts. The additional complexity to notice here is that Appium is never put to use by itself. Rather, it always requires that you use it together with a client library.
For some automation testers, there is another significant benefit. Appium actually employs the same protocol as Selenium—known as the WebDriver protocol. You can do many things with Appium by using a standard Selenium client. Often, this is enough to get a good start, especially if your plan is to use Appium to do web browser testing on a mobile platform.
However, Appium can do much more than Selenium. There are many Appium clients available in various programming languages, and these can extend legacy Selenium clients with considerably more functionality.
Starting Appium and running your first test
After following the process above, you can start the Appium server with a one-word command:
Appium
Appium will display a welcome message that contains the version of Appium and the port on which it is listening (default = port 4723). This port number is important to note since it will be necessary to direct your test client to connect with Appium on this port.
To help beginners write and automate their first Appium tests, the introductory documentation contains a good tutorial and additional references.
You might think that it’s easy going from here, especially since there is plenty of Appium documentation. There are, however, many challenges in using Appium. These challenges are similar to what you encounter with Selenium.
Challenges with Appium and mobile testing
Let’s look at the typical challenges in Appium test automation for mobile apps.
Initialization and configuration
There are a number of common issues that many new Appium users encounter, including:
Permissions — It’s important to be careful with permissions when installing Appium since you can encounter problems if you install it as a superuser.
Port number — You may encounter an error condition in which you can’t start a new session. This error is likely to be the result of a browser start-up failure. The solution here is to check the port number. Using the -p switch, set the port number when starting Appium to be the same port number given when initializing driver. It’s also necessary to correctly set Appium Capabilities.
Bad app — Another initialization error reads like this: “Failed to start an Appium session. Error: Bad app:” This error results from an incorrect app path specification—either in your project or the OS path for Appium app.
Scrolling to find all elements — Appium quickly exhibits scrolling issues, often because Appium can’t find elements that aren’t visible on the app screen. A workaround here is to create a generic method that scrolls through the entire page and finds each element (visible or not). Another good practice is to employ the Java method ScrollToExact() to scroll to precise locations throughout the page.
Overuse of XPath
Overusing XPath locators can be problematic with Selenium, and it has worse effects in Appium test automation. Though XPath in Appium can be quite effective in locating elements, using it incurs a fairly big hit to performance.
XPath- and XML-type queries are not provided natively Google and Apple. This induces Appium to make an excessive number of calls to reliably locate all elements. Though you can use XPath, there is a better approach to element location—accessibility identifiers.
Improper use of accessibility identifiers
As an alternative to XPath, seeking accessibility ID locators is preferable because it’s faster. It is, however, very important to remember that semantically accessible IDs are quite different than various other web page identifiers.
Accessibility IDs have an important purpose apart from testing. So, it’s critical not to confuse these IDs and potentially ruin the accessibility of your application in the pursuit of test automation. The key here is to choose accessibility labels that are readable by the human beings who are using them.
The challenges we touch on here with respect to IDs and XPath actually raise a bigger concern for teams that perform conventional test automation. The deeper issue that causes many automation efforts to fail is that the application has not been built to be testable. Testability is too often an afterthought.
Managing application view states
Another challenge arises when developers don’t set up their applications so that specific views and user states are quickly accessible.
Consider an example in which you have 12 different tests that exercise shopping cart functionality, with 10 of the tests running through the same steps of browsing to find various items to put in the cart. Such duplication is a huge waste of time. As a tester, you should expect that it’s easy enough to configure a state for an app and immediately run a test in that specific state.
This is highly significant with Appium since mobile emulators and simulators are often slow. These tools can require long periods of time to reach the correct step in the test.
Functionize: Fully Automatable Mobile App Testing
Functionize is a refreshing, highly effective alternative to conventional automation headaches.
In comparison with Selenium and Appium-based tools, you can enjoy far less configuration and maintenance tedium in getting your mobile testing setup. Most importantly, you’ll benefit from much greater reliability and efficiency.
Consider some of the many ways in which Functionize mobile app testing is superior to Appium approaches. Functionize:
- Determines if each and every application action executes correctly.
- Employs other methods to execute the action if it doesn’t execute correctly.
- Eliminates the need to rewrite scripts with every website change.
- Automatically detects site changes, then adapts or suggests test changes.
- Employs an in-depth element-selection process to ensure the correct element is chosen—even if selectors change.
Functionize platform architecture uses machine learning and AI to continuously refine tests to be more accurate and efficient. With such automation, there is no need to constantly update and maintain brittle mobile app test scripts. Your team can truly achieve high degrees of mobile testing automation.
