Transitioning from web to mobile testing? You're not alone. Many seasoned web automation experts find themselves wrestling with challenges unique to mobile apps–challenges that don’t always apply on the web:
- The elusive nature of elements in mobile apps, often because attributes are missing or misused
- The "visible view" constraint, where you only have access to the source code of what's currently on the screen
Here, we aim to shed light on these challenges, specifically as they pertain to web automation teams transitioning to mobile. We'll also explore how mabl’s built-in tools are designed to tackle these very issues.
Web DOM and the Mobile Equivalent
Web DOM Explained
The Document Object Model (DOM) is a tree-like representation of a web page's structure, where each element on the page is a node in the tree. The DOM is essential for automation because it provides a map for test scripts to pinpoint and interact with specific elements.
Let's take a look at a simple HTML code snippet and its corresponding DOM:
The Mobile "Page Source"
Mobile apps don't have a traditional DOM. Instead, they have what's usually referred to as the "view hierarchy" or "page source" (which is Appium’s specific interpretation of the mobile device's accessibility layer). This represents the structure of the screen you’re viewing, similar to the DOM. Take a look at this comparison of a web page's DOM and a mobile app's Appium page source:
While both layout a representation of the structural elements on a screen, there's a crucial distinction to keep in mind. The web's DOM offers a comprehensive blueprint of the entire webpage, even elements that aren’t in view. In contrast, Appium's "Page Source" provides a snapshot specific to what is visible on the mobile app's screen. It’s akin to comparing a detailed architectural plan of a building to a photograph of a single room within that building. This inherent difference underscores one of the key challenges in mobile automation: the need to navigate and interact with elements that might initially be off-screen.
Element Locators: The Backbone of Test Automation
As the identifiers that allow your scripts to find and interact with specific elements on the screen, locators are the linchpins of scripted test automation. The way they show up, however, isn’t always the same.
Web Element Locators: A Bounty of Locator Riches
In web automation, there is no shortage of attributes at your disposal: IDs, classes, names, CSS selectors, and even XPaths. When you inspect a page with DevTools you can see easily see the source code for a page and find an element’s tag, classes, attributes, contents, parents, and children:
When it comes time to start writing test code either in Selenium or Playwright so that you can interact with those elements, the locators are how you will be able to target them in your code:// Selenium - Find element by ID
WebElement element = driver.findElement(By.id("myElementId"));
// Playwright - Find element by CSS selector
const element = await page.locator('.myElementClass');
Mobile Element attributes: The Scarcity
For many reasons, mobile apps often lack the rich variety of attributes you can find in web pages. Accessibility IDs are supposed to serve a similar purpose, but they're frequently missing, misused, or simply unreliable.
For example, here’s a conceptual illustration of an Appium Page Source snippet:
<android.widget.Button The content-desc attribute (representing Accessibility ID on Android) is empty, making it harder to uniquely identify this button in automated tests. If another button on the same screen had the same resource-id or text value, it would create ambiguity for automation scripts relying on these locators.
text="Login"
resource-id="com.example.app:id/login_button"
class="android.widget.Button"
package="com.example.app"
content-desc=""
checkable="false"
checked="false"
clickable="true"
enabled="true"
focusable="true"
focused="false"
scrollable="false"
long-clickable="false"
password="false"
selected="false"
x="144"
y="528"
width="144"
height="48"
bounds="[144,528][288,576]"
displayed="true"
/>
Yet, when is comes to writing test code in Appium, you must find and decide on which element attributes to use in your code (as shown below):
// Appium - Find element by Accessibility ID (with potential pitfalls)
const element = driver.$("~elementId");
Why Mobile Test Automation is Harder
Fragile Locators
As seen in the examples above, web tests often rely on a wide range of attributes to pinpoint elements, while mobile tests are usually working with a scarce set of options. This scarcity means that even minor UI changes can disrupt tests, which requires more frequent updates and potentially slows down the testing process.
The Visible View Challenge
When setting up automation tests for the web, the entire DOM is available for inspection. Mobile automation testing, however, is limited to the "visible view"–you can only see the source code for the elements that are currently displayed on the screen. Because of this, mobile automation faces a major obstacle: scrolling, as many elements in mobile apps are only revealed after moving down the page.
Traditional scrolling methods in automation tools aren’t the most reliable, and finding elements that appear during the scroll is even trickier.
- Appium Scrolling Strategies: Appium offers several scrolling methods (scrollTo, scrollToExact, scrollIntoView, swipe, mobile:scroll) with varying levels of flexibility and control.
- Perfecto Swiping Techniques: Perfecto provides techniques like swipe, swipeTo, and visualSwipe, the latter being particularly useful when text-based locators are unreliable.
mabl's Solution: Intelligent Find & Scroll-to-Element
mabl's mobile app testing solution is designed to overcome the unique challenges of mobile automation by updating how we find locators and expanding our view.
Beyond Basic Locators
mabl doesn't rely solely on single attributes. Instead, our Intelligent Find feature captures multiple attributes for each element you interact with, creating a more robust and reliable identification mechanism. This means your tests are less likely to break due to UI and content changes, while also simplifying test creation, since you don't need to worry about choosing the "perfect" locator.
Conquering the Visible View
mabl's innovative Scroll-to-Element feature tackles the visible view challenge head-on. It intelligently scrolls to find and interact with elements that are initially off-screen, making your tests more resilient and less prone to scrolling-related failures.
Scroll to Element
Scroll within Element
For a deeper dive into how mabl's scroll-to-element works, check out our documentation on scrolling in mobile tests.
Wrapping Up
Mobile automation presents unique challenges that can trip up even seasoned web automation experts. The scarcity of reliable locators and the "visible view" constraint can make test creation and maintenance frustrating and time-consuming.
mabl's mobile app testing solution is designed to address these challenges head-on. With Intelligent Find and seamless scroll-to-element capabilities, mabl empowers your team to create reliable, scalable, and maintainable mobile tests, so you can focus on delivering high-quality apps at the speed of DevOps.
Ready to experience the ease and reliability of mabl’s mobile app testing? Try mabl free for 14 days and see how low-code test creation, advanced element finding, and seamless scroll-to-element can revolutionize your mobile testing. Empower your team to deliver flawless mobile experiences, faster.
