When I started doing automated testing with Appium and Python, my the first big challenge I faced was finding elements in the app. With the internet full of information it was weird to find that I had to browse through a bunch of articles and tutorials to actually find useful information. So here is one more tutorial that can hopefully give someone more knowledge on how to start finding elements with Appium and Python.
First we’ll look at the tools we will be using (Appium, Python, uiautomatorviewer and Appium Desktop) then we’ll take a look on all the different ways you are able to identify specific elements and lastly we’ll have a closer look at some code and how to make XPaths identifying specific elements.
Appium is a great mobile testing framework that derives its roots from Selenium and uses the JSON Wire Protocol, the Selenium WebDriver API and language-specific client libraries to interact with iOS and Android apps. Few of the big upsides with Appium are that it is an open source tool that can be used to automate native, hybrid and web app testing. Being able to write your tests once and run them on both iOS and Android is a huge plus. More about the platform support can be found here.
Every piece of code in this article is Python. If you have trouble finding the equivalent code for the language that you use, leave a comment and I, or another reader, will try to help you out. I will be writing this same article for iOS but for now, let’s focus on Android.
If you are developing the application and you know how the entire system works, it’s fairly easy to just write the tests and locate the elements with the ID’s you have written for them. But if you aren’t a developer in the application or you are new to the team, there are some great tools to inspect the application. These are the two I have used:
Uiautomatorviewer is probably the simplest way to inspect your app since it comes with the Android SDK Manager. So if you have Android Studio installed, you probably have uiautomatorviewer too. The uiautomatorviewer tool is located in the
<android-sdk>/tools/bin directory. When you open uiautomatorviewer with your app open and ask for it to take a device screenshot, you will get information about the app open in the device.
Appium Desktop is another great tool to use. It is basically a combo of Appium with GUI and uiautomatorviewer. Super easy to install from their GitHub page. As I’m writing this, the 1.10.0 is the latest release.
There are multiple ways (another resource) to identify a specific element. With the uiautomatorviewer and the Appium Desktop it’s fairly easy to figure out what those identifiers are and what of those you can use to find elements. The ones I cover in this article are:
- Accessability ID
- Class name
- ID (resource-id)
And the ones I won’t be gettin into in this article:
Writing tests in Appium is pretty straight forward assuming that you have a basic understading of programming, testing and the app being tested. For this article, I wrote a basic test identifying the button for ‘9’ in the calculator and clicking it. I figured this would be a good example, since everyone has a basic understanding on how the calculator app works and number ‘9’ used to be my player number when I played basketball as a kid. With some of the examples I had to use the ‘delete’-button, because the number ‘9’ didn’t have all the props to identify the button with. Here’s the code:
I’m going to explain some parts of the code. setUp() that gets run before every test and tearDown() gets run after every test. In setUp() we have the desired capabilities and the Appium server ip. The desired capabilities have all the important information that is needed to run the tests, like what app are we testing, what device we are using etc. The function of tearDown() is simple in this case: it closes the app.
Finding an element using the resource-id:
find_element_by_id('com.google.android.calculator:id/digit_9') is pretty straight forward, you can see it straight from the uiautomatorviewer or Appium Desktop. It should be unique and your best bet.
Another great way is to find an element in your app is to use the
find_element_by_accessibility_id('delete'). Accessibility id should also be an unique identifier. If neither of these are coded in to the application you need to use XPath.
XPath is a great way to identify elements that don’t have other unique identifiers but it also the trickiest way to do it. A nice way to think about xpaths is that they are like directions you would give a friend. They can start from the root or from anywhere in the middle of the path. All of the xpaths in the example start in the middle (so they use the //, if you would use the full path it would start with /).
The problem with xpath locators is that they are easy to break when making changes to the code. With accessability_id or resource-id the test will probably not break even if some changes are made to the code.
You can also use the plural
find_elements_by_* to find all the elements that corresponds to that definition. This returns a list and you can use the index to pick the correct one.
Hope this helps! I’ll try to write more tutorials and articles on what I’ve learned at work and on my free time projects. If you have suggestions on articles, let me know in the comments.