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:
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.
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:
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:
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.
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');
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");
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.
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.
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.
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.
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 within Element
For a deeper dive into how mabl's scroll-to-element works, check out our documentation on scrolling in mobile tests.
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.