Appium 2.0 will soon be the only supported version of Appium. What do you need to know about updating your test scripts so that they keep working when you upgrade? This is the first part of an open-ended series detailing the breaking changes you might encounter when migrating to Appium 2.0
On Appium Pro we talk a lot about specific automation techniques, but we don't often talk about the philosophy or the art of testing. Let's do that now, with a thoughtful introduction to what testing itself is.
Sometimes, finding an element isn't enough to tap on it. You call the element.click() command, but nothing happens! By building a tap-by-location helper, you might be able to get things working agian, especially if the problem is that you need to tap somewhere other than the midpoint of your element.
Many apps are not 'single-player,' so to speak. They involve the interaction of multiple users, sometimes in real time. Classic examples would be ride hailing, food delivery, or chat apps. While it's possible to mock out all except one of the parties, to get full end-to-end coverage of these scenarios, it can be useful to run multiple simultaneous Appium sessions, on different devices, to act out the various flows for the various participants, all just as it would happen in an actual use case.
RPA is a massive and growing part of the software industry, focused around the automation of repetitive business processes. While it has its own name and its own use cases, RPA is really not distinct from the tools and processes used in UI test automation. In this edition we take a look at how you can use Appium for all your RPA needs.
Appium usually requires an 'app' capability so that it can launch an app that you want to test. But what if you don't want to test any app in particular? In this case, we can decide to start with the 'Springboard' app, which is another name for the iOS home screen or app launcher.
When waiting for app state, you're not limited to the built-in expected conditions from the Appium client libraries. You can also create your own expected conditions, which neatly wrap up information about app-specific state, and potentially include helpful side effects as well. As a case study, we examine a particular custom expected condition I created for use with automation of the Zoom app, following an Automation Happy Hour.
Sometimes, for reasons that are currently unfixable, Appium returns screenshots on iOS that don't match the actual orientation of the device screen. This varies based on type of device, iOS version, etc... Luckily, Appium has a special setting you can use to always enforce a certain orientation for the screenshot, if you know what it should be.
At the end of the day, Appium and Selenium are just web servers. That means we can interact with Appium just like we could with any other REST API, including using command-line tools like curl to generate raw HTTP requests directly to an Appium automation session.
One of the greatest features of iPadOS is the ability to run multiple apps at once on the same screen, for a more powerful set of workflows. Using Appium and a bit of thoughtful hackery, we can mimic the user behaviors needed to enter into this Split View Multitasking mode.
Making sure swiping and scrolling happens equivalently across platforms, and in a way which is super convenient to access from test cases, can be a challenge. In this article I walk through the process of building such a helper in Java.
Getting the notifications that various apps can leave on your system is a challenging task. Thankfully, Appium has found a way to communicate with its helper app to retrieve these notifications for you and return them to your test script along with a ton of potentially quite-useful metadata.
We wrap up our long series on mobile performance and UX testing with a look at some of the non-free tools or services available to assist with the task. Some of these services provide a way to get performance reports for free as a result of an Appium test. Other tools are standalone products that can be used alongside Appium, but might require some extra setup on your part.
Having already looked at network and performance testing from a high level, in this article we dive into specific tools and techniques for capturing some of the most relevant performance and UX metrics for mobile apps.
What is mobile app performance? How do we know what to track and how to interpret what we find? In this part-FAQ, part-interview, we explore a host of topics that take us to the edge of thinking about mobile app performance as a significant component of mobile app UX.
Appium and Test.ai have been partnering on bringing AI to open source testing for some time. In this article we take a look at how the technology which powers the Appium element classification plugin can also be applied to Selenium, with reference to special new client libraries created for Java and other languages that can help bring a little bit of AI to your Selenium tests.
In Part 3 of this visual testing series, we tackle the remaining problems that can plague a mobile visual testsuite, including the challenge of full-scroll screenshots and what to do about screen regions that host changing content and can lead to false positive results.
In this second part of the series on visual testing, we think about some of the problems that exist with our home-grown visual testing solution, and explore how the Applitools Eyes SDK is well-suited to making our visual testing more robust and maintainable.
You can use Appium for more than functional testing. Another very important category of testing is visual testing, wherein visual elements of the app are compared across runs to ensure that there are no visual discrepancies, which could be a sign of visual or even functional bugs. This is the first in a 3-part series showing how to use open source as well as industry tools to be successful in visual testing.
App launch time is a significant performance metric, since it defines a user's first experience of your app. Luckily, with a bit of hackery, this is easy to determine using Appium. Combined with the use of a device cloud service (in this article we explore AWS Device Farm), it's within the reach of most test teams to track app launch performance over time.
When running tests of mobile websites with Appium, it can sometimes be advantageous to work with cookies that have been set in the browser by the application server, using the built-in cookie management commands.
Sometimes, it is impossible or inconvenient to find elements that have not yet been rendered by the Android UI subsystems. Using the Espresso driver, we have access to a special locator strategy that enables us to access elements which have data bound to them, even if the elements themselves are not yet visible.
The Appium Events API can be useful for getting a clear look at what's happening underneath the hood of your test, along the dimension of time. Using the Appium Event Parser, you can also generate a timeline to visualize events within Appium itself and within your own test script.
Appium uses Chromedriver to automate Android web and hybrid apps. Chromedriver is great, but it comes with its own wrinkles in terms of Chrome version support. In this edition, we take a look at four strategies for approaching these challenges.
Finding elements via a template image is a powerful technique for automating apps with non-standard UI elements, as well as games. It can be tricky, though, to know how to appropriately use the threshold setting for finding image elements. In this edition we take a look at a technique for setting this threshold experimentally.
Appium supports a whole host of platforms by means of a large array of 'drivers', each of which is responsible for translating Appium's own protocol to automation behaviors on a particular platform, using a particular automation technology. Learn all about this system, and how to choose the right driver for your testing.
It's all too common to end up in a position where you're trying to debug a test that was run remotely, without access to any of the data that would make debugging possible. Learn how not to end up in this position by setting your test cases to automatically retrieve and save useful debugging information on test failure.
Android 10 comes with a few changes to the permissions model that might cause issues for app automation, especially of older apps. In this article we take a look at how to work around these changes and keep the automation rolling.
When using Appium with cloud services, we can sometimes be victims of too many network hops and proxies. However, if the cloud service supports the `directConnect` response capabilities, it can make our lives a lot easier.
Appium's client/server model has some disadvantages when it comes to encountering network legacy for each command. Appium has a way around this challenge, by allowing you to batch up commands into a group to be executed server-side.
Deep links are a great strategy for speeding up test execution. However, due to differences between platforms and virtual vs real devices, they can be challenging to implement. It is possible however, by using a mix of cleverness and old-fashioned brute force.
React Native is a popular app development framework that enables native user experiences while maintaining a mostly single platform developer experience. Testing React Native apps with Appium is relatively straightforward, but there are a few tips that might make the difference between a successful and and an unsuccessful Appium testing expedition.
Appium can go far beyond automation of mobile apps. In this second installment of the Appium + IoT series, we look at how to write test code that runs on a custom Appium driver built for the Raspberry Pi GPIO pins.
Appium is useful for more than just automation of mobile apps. In fact, Appium can be used to automate platforms that have no visual UI at all, such as custom IoT devices or electronics project. In this series, inspired by the AppiumConf 2019 keynote, we look at how to use Appium to test a completely custom piece of electronics hardware.
Some Android apps are built with multiple webviews, and they're a bit tricky to work with because they don't show up in the context list as you'd expect. Thankfully there's an easy workaround which enables automation of any number of webviews.
In the second part of this audio testing series, we look at the all-important step of audio verification, which boils down to determining how similar two different audio files are. This is no easy task, but thanks to the existence of audio fingerprinting libraries, it's one we can handle.
It's not particularly easy, but it is certainly possible to capture and verify audio output for your apps. In the first of this two-part series, we explore the techniques available for capturing audio playback and making it available for later verification.
Mobile devices are not always pure screen--they have physical buttons as well. Using Appium's mobile executeScript methods, it's possible to automate several of the physical hardware buttons on an iOS device.
Built-in apps which come preinstalled on devices can be automated by Appium on both iOS and Android. This is especially useful when it comes to automating the settings apps for special test requirements.
A common app notification method on the Android platform utilizes 'toast' messages, which are displayed for a brief period of time and then disappear. Using methods available in Appium's Espresso driver, in conjunction with Explicit Waits, it's possible to verify the behavior of toast messages within your app.
Sometimes working with iOS's pesky picker wheels can be an automation challenge. There are two methods for dealing with picker wheels, including a special method custom-designed to work with picker wheels even when the desired value is not known beforehand.
When we're automating mobile web and hybrid apps, it can be hard to know which selectors and locator strategies to use to find particular elements. Tools like Appium Desktop or uiautomatorviewer are no help here, but that's for a good reason: our browsers come with all the tools we need to solve this problem already.
Running your Appium tests in parallel is great, but using one Appium server doesn't scale to meet the needs of a production CI environment. For that, the best DIY option is Selenium Grid, which is a WebDriver-specific load balancer and proxy. Using Selenium Grid, you can easily add and remove capacity from your test grid, and mix in Selenium-based testing seamlessly alongside your Appium mobile tests.
Android devices record detailed system logs, commonly referred to as 'logcat' logs. These logs sometimes contain information pertinent to tests, and can be easily read and saved from remote devices through the various Appium clients.
Appium, combined with the power of Espresso, can finally break its way out of the black box testing model. Whether this is something you want to do is of course up to you, but using the mobile: backdoor method, you can trigger app-internal methods with arbitrary parameters.
Did you know that you can use Appium to do all kinds of things, including scripting your holiday donation to your favorite charity? Here's a little example to get you inspired to think out of the box with using Appium as a force of good in the world.
Add some sparkle to your Appium test by making elements flash! Not only a party trick, this can be a useful technique for debugging your test scripts to visually verify that you've got a handle on the elements you think you do!
The W3C Actions API is about more than building complex touch gestures. It extends to full control over the keyboard (virtual or real), and allows for fine-grained control of keystrokes. Using this portion of the Actions API, you can trigger key input in your app without having to first find an element and then use `sendKeys` on it specifically.
'Siri, how do I automate you with Appium?' While Siri won't have the answer to that question, this edition of Appium Pro does! You can test your app's SiriKit integrations using Appium's `siriCommand` method.
Web Components are an amazing new web standard that promises to ease the pain of code sharing and UI component reuse across your apps and across the web. They do, however, come with a few headaches for testing, since the very thing that makes Web Components sharable and reusable also makes their inner workings hidden from the outside world. There are several strategies for getting inside the Web Component Shadow DOM, however.
Just as you can generate artificial text messages to an Android emulator, so you can also convince an emulator to believe it's receiving a phone call! Appium has a simple API for triggering incoming phone calls from arbitrary numbers, which can be useful for a variety of reasons, not least of which is making sure your app stays functional during a call.
There's been a lot of discussion around the potential ramifications of AI for automated testing. While the debate will no doubt rage on, Appium and Test.ai have teamed up to release a simple integration which allows you to find elements using a machine learning model, making it possible to find icons in your app without knowing anything about your app or looking up selectors.
When using Chrome on Android, or Chrome-backed webviews, it is possible to retrieve logs written by web applications (or hybrid applications) to the browser console. Retrieving these logs is useful for a number of reasons, from observing app state to saving app-internal logs along with test artifacts.
A lot of information is transmitted through the browser console, some of which is very useful, especially in cases of app errors. Using the log retrieval capabilities of the Appium client, we can gather browser console messages for storage as a test artifact or even to make assertions on app state.
When automating web applications using Appium, we sometimes run into situations where clicking an element doesn't appear to do anything in our tests, even though clicking the element manually works. The nativeWebTap capability comes to our rescue!
We hear a lot (from Appium Pro and other places) about how it's not a good idea to use XPath. That's generally correct. There are times, however, when it is totally fine to use XPath, or when XPath is the only option. In this edition we take a look at how to write good XPath queries to minimize the XPath blast radius.
Appium automation doesn't necessarily stop at the edge of the screen. Your Android device has hardware buttons (power, volume control, etc...), and Appium gives you the ability to automate these as well, using a generic KeyEvent interface from Android.
We've already seen how to find elements by image, but this doesn't always work out of the box. There are a number of knobs, dials, and switches you can play with (in the form of Appium settings) that help modulate the behavior of the image matching procedures. These will help fine-tune and stabilize your find-by-element usage.
When you just can't find an element, whether because it's built using non-standard APIs or has no uniquely identifying markers, it's possible to fall back to image matching via a template image. This technique, when used appropriately, can help overcome roadblocks to automation.
Alerts in native mobile apps don't always work exactly the same way that alerts in web browsers do, which means we need a bit more than the WebDriver spec can give us. Appium has a special command to help manage the extra buttons that can be present in mobile alerts. In this edition we take a look at how it works on iOS.
Sometimes using the standard Action APIs leads to undesired behavior due to the not-always-perfect mapping between the WebDriver spec and the available mobile automation technologies Appium uses. That's why Appium also makes platform-specific action methods available for 'direct' access to underlying action automation methods.
The ability to automate all the actions a user could take is essential, and that extends to touch gestures like pinch, zoom, and tapping with custom durations. Appium can do all this and more, with its support of the W3C Actions API that allows the encoding of arbitrary touch input behavior.
The best way to achieve a speedy build when it's full of Appium tests is to run those tests in parallel. In this article, we explore how to set up parallel testing locally, utilizing either multiple Appium servers or just a single server hosting multiple sessions.
Rounding out this series on speed and reliability, we consider failure resolution strategies. How do you debug issues? How do you locate a problem in the Appium stack? Where do you report bugs? And so on.
One of the most common causes of instability or non-determinacy in tests is due to dependence on external services, like a backend API server. Often, when testing your app it is not really necessary to simultaneously test these backend services, and a 'mock' server can be used instead, which greatly increases both the speed and reliability of your tests.
Animations in mobile apps are part and parcel of the beautiful app experience we've all come to expect. They are, however, completely useless for testing. In this edition of the 'Fast and Reliable' series, we look at how to turn them off completely, or otherwise reduce them to speed up our tests and improve test stability.
You don't have to settle for 'default Appium'. If you find yourself in a place where you're experiencing issues, or want to try a different operational mode, there are a ton of desired capabilities you can check out that modulate the way Appium works under the hood. You might find that the problem you're experiencing has a well-known workaround in the form of a desired capability you can simply plug into your driver initialization.
Functional tests are kind of slow. It's sad, but it's a fact of life and something we don't need to get too concerned about if we remember that, just as in the Matrix, 'there is no spoon'! We can use a variety of techniques to set up app state directly, without having to automate the UI, so that our UI tests can test only the steps which we actually care about for a particular scenario.
Sometimes, for whatever reason, we need to interact with elements that Appium can't find as elements. What can we do when there's no element to call 'click()' on? Hacky things, that's what we do. But we do the hacky things as reliably as we can.
In this edition of the miniseries on speed and reliability of tests, we examine a very important aspect of writing any functional test: making sure that the app is in the state you expect before you attempt to interact with it. Here we learn how to ensure your assumptions about said state are correct.
Continuing a larger Appium Pro series on making tests more robust, in this episode we examine the various locator strategies available within Appium, when to use which, and other approaches and practices to making sure your elements are found and not lost.
In this article we start a series that takes a look at a collection of tips and best practices that all contribute to greater speed and reliability of your Appium tests. First off, we discuss the dreaded concept of test 'flakiness', and how we should approach this concept within the world of Appium.
Espresso and Appium?! That's right, you can access the power and reliability of Google's flagship Android automation technology from within Appium, retaining the ability to write WebDriver-compatible scripts in any programming language.
Hybrid apps contain both native and web components, melded together in some ratio to provide a single unified app experience for the user. With Appium and the various Context commands, it's possible to successfully automate both halves of hybrid apps across both iOS and Android.
Both iOS and Android allow copying and pasting of text and other types of content. Apps can hook into this native clipboard and provide custom experiences based on clipboard content. Appium gives you special commands to automate the clipboard across both platforms.
Sometimes you need a mobile software robot like Appium for something other than your day job. In this article I break down my AppiumConf 2018 demo, giving a behind-the-scenes tour of how I managed to coax Appium to act as the director of a software band which accompanied my performance of the original song 'Ghost in the Machine'.
Sometimes being able to automate your app-under-test (AUT) is not enough. People don't have just one app on their phone, and oftentimes your app depends on actions taken in another app. How do you test multi-app flows like this? With Appium, of course!
App usability is about more than functionality: if the user experience isn't snappy enough, it can be a big problem. Performance testing and analysis is an important phase of testing. Thankfully, Appium can gather performance data during the course of your iOS tests.
Running into problems with Appium can be a frustrating experience. Sometimes you just get a cryptic, unhelpful message as part of an error thrown in your client code. Where do you go next? The Appium logs! This is a guest post from Isaac Murchie on how to take advantage of reading the Appium logs to help understand what's going on and potentially resolve issues.
It's important to test that user data and user experiences are not broken due to changes between app version upgrades. Appium comes with some built-in app management commands that make it possible to test how your app behaves across versions, all within the context of one Appium session.
If you've used Appium for any length of time, you've probably encountered the sad fact that, sometimes, xpath element queries are slow. In this newsletter, we explore why that is the case for iOS, and explore the various alternatives to XPath available to us, especially the little-known 'class chain' locator strategy.
Appium tests are full-UI functional tests. They can take a long time to run. It's a good idea to look for shortcuts so that your tests don't have to spend a ton of time setting up state, and can instead focus on just the bare minimum they need to validate. With a little work, you can accomplish this using deep links in both iOS and Android.
It's important to test that user data and user experiences are not broken due to changes between app version upgrades. Appium provides some helpful commands to test iOS app upgrades all within the context of one Appium session.
Functional testing is not the only kind of testing that Appium supports. As a pure automation library, Appium can also be used in the service of performance testing. In this edition we take a look at an example of performance testing on Android, namely how to track memory usage over time and make assertions about it.
Appium is not just for native apps. One of the great things about Appium is being able to test multiple app modes. You can even use Appium to run tests against regular old web applications on mobile devices.