Implementing UI Automation Testing for Mobile Apps with Appium and Cucumber
This article explains why UI automation testing is essential for complex mobile apps, why Appium is chosen, how to organize test cases with Cucumber, implement custom steps, locate elements using various strategies, handle common exceptions, and outlines the overall workflow and improvement suggestions.
Mobile applications are highly coupled systems where unit tests alone cannot guarantee overall functionality; UI automation testing is therefore a crucial part of the development process to reduce repetitive work and improve efficiency, especially when integrated into continuous integration pipelines.
Appium is introduced as an open‑source tool that supports native, hybrid, and web applications on Android, iOS, and Windows. It leverages each platform's native testing frameworks (UiAutomator2, XCUITest, etc.), requires no additional code injection, and benefits from an active community that continuously adds features such as log collection, screen recording, and image‑based element recognition.
To improve test readability and maintainability, Cucumber is used to write BDD‑style test cases. A simple click step is defined as:
"当 点击 [元素名称]"and implemented in Java with regular‑expression matching:
// Cucumber uses regex to capture the element name as a parameter
@当("^点击 \"([^\"]*)\"$")
public void findElementAndClick(String type) throws Throwable {
// driver abstracts the Appium device
driver.findElement(By.id(type)).click();
}Test cases are organized using the Page Object pattern, where each UI screen is represented by a Page class containing element locators (e.g., com.huajiao:id/main_home_top_search ) and common actions such as click, swipe, and input.
Complex custom steps that require branching or loops are implemented directly in Java. An example of a logout step that handles both logged‑in and logged‑out states demonstrates the use of try‑catch and AndroidKey actions.
@当("^退出登录$")
public void logout() throws Throwable {
// Click "Home‑My"
onView(By.id("com.huajiao:id/bottom_tab_user")).perform(click());
try {
// If logged in, element is visible
onView(By.id("com.huajiao:id/bottom_tab_user")).check(matches(isDisplayed()));
logOut();
} catch (NoSuchElementException e) {
// If not logged in, close the login popup
onActions().pressKeyCode(AndroidKey.BACK, "1").perform();
}
}Appium provides multiple element‑location strategies: By.id , MobileBy.AndroidUIAutomator , XPath, and image‑based lookup ( MobileBy.image(base64ImageString) ). While XPath offers precise targeting, it can be brittle and slower on iOS; resource‑id is recommended when possible.
Common pitfalls such as StaleElementReferenceException are discussed, explaining that cached element references may become invalid after page transitions or unexpected pop‑ups.
The overall workflow includes:
htest client fetches the latest APK, installs it, and triggers BVT test cases.
The test platform translates Cucumber steps into element locators and sends them to the client via HTTP or socket.
During execution, the system detects and dismisses unexpected pop‑ups before retrying element searches.
Appium driver performs the actual UI actions on the device.
On failure, logs, screenshots, and recordings are collected and reported back to the platform.
Identified issues and improvement directions include supporting parallel execution on multiple devices, enhancing video capture with scrcpy, and combining image‑recognition plugins to locate custom controls that lack resource‑ids.
360 Tech Engineering
Official tech channel of 360, building the most professional technology aggregation platform for the brand.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.