Mobile Testing in Appium: 3 Advanced Automation Techniques

Appium is the de facto automation framework for testing mobile applications. But you may not be getting all you can out of mobile testing with Appium. Teams may not know they can automate advanced testing scenarios with the framework.

Keep reading to learn Appium automation techniques that will allow you to automate more of your test cases.

3 Advanced Appium Automation Techniques

1. In-App Authentication Using Face-ID

One new feature from Appium is in-app authentication using face ID. A lot of applications use face ID for signing in or to perform a payment. So it is important for face ID to work perfectly.

Related Reading 👉 The Complete Guide to Mobile Automation Testing >>

Appium is able to support testing in-app authentication on iOS simulators using face ID. And it supports touch ID authentication on older iOS devices.

Face ID support is only on iOS simulators, not on the real devices. And it has only three limited controls:

• Enrolling the face, which is similar to scanning a face during device setup and enabling the feature altogether.
• Matching of the face.
• Unmatching the face.

Appium strictly follows W3C standards, which is the WebDriver protocol. And some of these features of in-app authentication using face ID are not defined in the W3C standard. Appium provides another way of utilizing these kinds of features specific to platform, which is using mobile supporting methods.

Mobile Supporting Methods

Appium defines its own API and exposes us to the outer world using mobile supporting methods.

One is “sendBiometricMatch” which takes up two arguments:

• Face ID and the exact value for it could be true or false to perform a perfect match.
• Perform a non-matching face to figure out how the application behaves when we do a face mismatch.

There’s another mobile supporting method specific to enrolling the biometric. It takes up the argument of 'is enabled.’ It can be either true or false. And it is okay to enable this multiple times — the simulators are clever enough to understand it.

Related Reading 👉 Mobile App Testing Checklist

But on a valid case, it is good to interpolate probably once per test, or once altogether. And then we can use a “sendBiometric mismatch.” Once it is enabled, we can send actual face ID authentication either true or false using the mobile supporting method called “sendBiometricmismatch.”

2. Appium’s Events API

Another cool feature recently introduced is Appium's Events API.

Appium under the hood uses WebDriver agent. There are a lot of things that happen under the hood when Appium scripts run to perform actions on the application under test.

One such thing is bundling the WebDriver agent and installing it on the real device or on the simulator. It takes a bit of time. In order to understand how much time it takes, we have the “log timestamp” capability. But it's very difficult to understand how much time that a certain process takes.

Related Reading 👉 10 Types of Mobile Testing Your Apps Need

For example, starting a simulator probably took two seconds on simulator A and probably five seconds on simulator B. But if we have multiple simulators up and running, it's going to be very difficult.

How Events API Will Help

Appium's Events API is going to solve is this mess. It’s going to help us to understand better how much time the simulator A took to start and simulator B took to start.

Related Reading 👉 XCUITest vs. Appium vs. Espresso

So you can use Appium Events API, which has inbuilt events called server events. One of the server events is nothing but excluded detailed retrieval. Simulator starting time is another server event. These are some of the server events that Appium provides us by default.

But there are also custom events.

Custom Events

Here’s an example of a custom event: you want to understand how much time an application takes to navigate from screen A to screen B. It's quite possible to understand how much time this navigation takes from screen A to screen B using Appium Events API.

This custom event can be defined with the vendor and also an event name. This is to enable some differentiation between Appium zone server events, like simulator start time, and our own custom events specific to our application.

Related Reading 👉 Test Automation Strategy For Beginners

Here we have a defined set vendor which is VodQA, one of the sample apps that we will demonstrate (see below). And the event name is OnLoginScreen.

We can start providing event names and then log these events whenever we feel that we navigated from screen A to screen B. Then we can log another event to understand how much time that we spent on the second screen. It gives us an idea of how much time a particular event takes in automating our application under test.

See a demo of an in-app authentication iOS test and Appium events at 17:00 of this recorded webinar >>

3. Streaming Apps on a Browser

Another advanced Appium testing technique is streaming your application onto browsers.

With Appium, there are two different APIs for when you start and stop video recording. But there is an advantage with this. Once you start recording your screen, you can actually hit a specific port on your browser, where the specific screen is being displayed. Let's say you move from screen one to screen two. You can typically actually see those navigations of the screen from your device onto the browser. And how is this happening?

Under the hood, it uses FFmpeg in the server, and this streams it into the browser. And if you need this feature to be workable with your Appium version, all you need to do is you need to install FFmpeg on your machine, and it should be in the path so that Appium can locate it. 

Streaming Across Devices

If you are running tests across devices, you may be wondering how to configure the port numbers. If it is one device, by default, Appium starts this FFmpeg server on 9100, so if you look into your Appium logs, you could actually see a lot of information there.

If you are running your tests across multiple simulators or devices, and you want to actually look at your screen on the browser. In that case, you have to give different, unique ports. You could do this through another capability called end MJPEG server URL.

You can look at a capability list — they are more than 280 capabilities for both iOS and Android together. You could see that there is a capability for this, where you can set the port number to a random one and it’s going to stream a specific device screen onto your browser.

What About Android?

Now what happens to Android? For Android, we don't have direct APIs, which we could use. But there are third party streaming applications you can install on your device and start your streaming and you could get the port number and do exactly the same for what we did with iOS.

If you need to know more about how we do this for Android and what sort of streaming applications are there, you should definitely go to Appium Pro blog, by Jonathan Lipps.

See a demo of video stream at 33:30.

The Bottom Line

Now that you’ve learned advanced Appium automation techniques, make Appium even better by pairing it with Perfecto. Leveraging a cloud testing solution like Perfecto means you can create, run, and analyze your test automation with Appium on real devices in the cloud.

With Perfecto and Appium for mobile app testing, you’ll be able to:

• Scale your existing testing across platforms.
• Find and fix bugs faster through advanced reporting.
• Integrate test automation into your CI/CD pipeline.

See for yourself why Perfecto makes mobile testing with Appium so much better. You can get started with a free 14-day trial of Perfecto today.

Try Perfecto

Related Content

• Appium Tutorial: Guide to Mobile Testing in Appium
• 14 of Your Appium Questions Answered
• Sharpening Your Mobile App Test Automation Skills With Appium
• Complete Guide to Appium Basics