Features

Our blog.

TestingBot provides a cloud of browsers to run Automated, Live and Visual browser testing.

< Back to Blog Overview

Mobile Locators for Automated Testing

2019-11-21

TestingBot provides a large grid of mobile devices and simulators/emulators to run Automated and Manual tests against your mobile apps.
An important part when creating automated tests is to locate elements. Elements can be buttons, text fields, input fields, any component in your app.


Your test will need to locate these elements before it can interact with them, so setting up and finding elements is an important part in creating and maintaining automated mobile tests.

Mobile Inspector

Similar to Appium Deskop's element locator, TestingBot has added its own Mobile Inspector to the Live testing feature on Real Mobile Devices.


Simply upload your mobile app (.apk or .ipa), select which physical device you want to test on and click Start.


TestingBot will load a live view of the device, and allows you to interact with the device with your mouse and keyboard; tap, swipe and all other gestures are available.


With the Live View of your App, you will see a live output of the device logs on the left of your screen. This makes it easy to troubleshoot or find issues with your app.


Another tab called Inspector will take a live snapshot of the element structure of your app, and present it in a tree format, similar to Appium Desktop's inspector view.


You can expand and collapse each node in the tree. Each node represents an element, which has a unique identifier that can be used for your Automated Tests.


While hovering over each element, we will highlight the element on top of the live screen of the device and show you a list of details and possible locators that can be used.


We support several locator strategies, including locators such as accessibilityId and testID.


Mobile Locator Strategies

In general, these are the locator strategies which are available for Automated Testing:

  • Id
  • XPath
  • Name
  • Class Name
  • Accessibility ID
  • UIAutomator Selector (Android UiAutomator2)
  • DataMatcher Selector (Android Espresso)
  • Android View Tag (Android Espresso)
  • Predicate String (iOS)
  • Class Chain (iOS)

Currently, our Inspector will retrieve the following locators:


  • Id (TestID)
  • XPath
  • Name
  • Accessibility ID

If you or your team is developing the mobile app, we recommend using Id, Name or Accessibility ID as much as possible, since XPath locators are prone to change when your app layout changes.
By specifying your own locators, you can give your elements clear locator names, which helps the readability of your test.
An added benefit of using Accessibility ID is that you make sure your app works well for people with disabilities.


Mobile Locators Overview

Below is a short overview of the different locator strategies, together with some examples.


class name

  • For iOS, this refers to the UIA elements.
    <UIATextField name="fbemail" label="fbemail" value="We really would like to follow up!" dom="" enabled="true" valid="true" visible="true" hint="fbemail" path="/0/0/0/13" x="5" y="264" width="275" height="31"></UIATextField>
  • For Android, this refers to the fully qualified name of the UI Automator Class. For example, android.widget.EditText for a Text Input Field.
    <uiatextfield name="fbemail" label="fbemail" value="We really would like to follow up!" dom="" enabled="true" valid="true" visible="true" hint="fbemail" path="/0/0/0/13" x="5" y="264" width="275" height="31"></uiatextfield>

id

This is the native element identifier, which is the resource-id for android and the name for iOS.


name

Name of the element in iOS and Android.


XPath

Goes through the app XML tree to search for the element. This might be slower, depending on how many nodes there are in the tree (how complex your layout is).
An Xpath locator looks something like this: //a[@id="abc"][@for="xyz"]


Accessibility ID

A unique identifier for an element. For iOS it is the element's accessibility-id attribute and for Android it is the element's content-desc attribute.

Using locators in a Test

Now that you're ready with the locators, how about using them in an Automated Mobile Test? Below is an example of a test, where we open an app on Android, locate an element (inputA) and then enter text into that element (textfield).

require 'rubygems'
require 'appium_lib'

caps = {}
caps['name'] = 'Ruby Appium Example'
caps['deviceName'] = 'Galaxy S10'
caps['platformName'] = 'Android'
caps['version'] = '9.0'
caps['app'] = 'https://testingbot.com/appium/sample.apk'
caps['realDevice'] = true

appium_driver = Appium::Driver.new({
    'caps' => caps,
    'appium_lib' => {
        :server_url => "https://API_KEY:API_SECRET@hub.testingbot.com/wd/hub"
    }}, true)
driver = appium_driver.start_driver

wait = Selenium::WebDriver::Wait.new(:timeout => 30)
wait.until { driver.find_element(:accessibility_id, "inputA").displayed? }

driver.find_element(:accessibility_id, "inputA").send_keys 5
driver.quit

Conclusion

Mobile App Testing is very powerful and should definitely be a part of your development cycle. Creating mobile tests with optimised locators will help you in releasing better mobile apps, faster.

Sign up for a Free Trial

Start testing your apps with TestingBot.

No credit card required.