One of the biggest difficulties involved in functional testing is that functional tests can be slow. Some functional testing frameworks are faster than others, and I'll be the first to admit that Appium isn't always as speedy as I would like. Speed itself is a topic for another time! This edition is all about how to make automation speed less important overall, by building shortcuts into your testing.
What do I mean by shortcuts? Let's take logging in to an app as an example. Most apps require some kind of login step. Before your tests can access all the functionality they're supposed to exercise, they must first log in. And if you are keeping your tests atomic, as you should, every test has to log in separately. This is a huge waste of time. You only need to run Appium commands on your login screen when you are actively testing the login functionality. For every other test, it'd be great to just land somewhere behind the authentication barrier and get directly to business.
We can accomplish this on iOS and Android with something called a deep link. Deep links are special URLs that can be associated with specific apps. The developer of the app registers a unique URL scheme with the OS, and from then on, the app will come alive and will be able to do whatever it wants based on the content of the URL.
What we need, then, is some kind of special URL that our app interprets as a login attempt. When it detects that it has been activated with that URL, it will perform the login behind the scenes and redirect the app to the correct logged-in view.
I recently spent some time adding deep link interpretation into The App. Exactly how I did that is beyond the scope of this edition and is specific to React Native apps in any case. There are plenty of tutorials online for adding deep link support to your iOS or Android app. But what I ended up with in v1.2.1 is support for a deep link that looks like this:
In other words, with The App installed on a device, we can direct the device to navigate to a URL with that form, and The App will wake up and perform authentication of the requested username/password combination behind the scenes, dumping the user to the logged-in area instantly. Great! Now how do we do the same thing with Appium?
Also read: How to Test iOS Face ID with Appium
It's easy: just use driver.get. Since the Appium client libraries just extend the Selenium ones, we can use the same command that Selenium would use to navigate to a browser URL. In our case, the concept of URL is just ... bigger. So let's say we want to log in with the username darlene and the password testing123. All we have to do is construct a test that opens a session with our App Under Test, and runs the following command:
Of course, it's up to the app developer to build the ability to respond to URLs and perform the appropriate action with them. And you probably want to make sure that URLs used for testing are not turned on in production versions of your app! But it's worth building them into your app for testing, or convincing your developer to. Being able to set up arbitrary test state is the best way to cut off significant portions of time off your testing. In my own experimentation with The App, I noticed a savings of 5-10s on each test just by bypassing the login screen in this way. These savings add up!
Here is a full example. It shows two ways of testing that the logged-in experience works correctly: first by navigating the login UI with Appium, and then by using the deep linking trick described in this edition. It also shows an example of what an extremely simple inline Page Object Model might look like, as a way to reuse code as much as possible. You'll also notice that because my app is cross-platform, I'm able to run these tests on both iOS and Android with minimal code difference.