A mobile test automation framework that passes sequentially and collapses under parallel execution isn't flaky. It's single-threaded by construction — one driver instance, screen objects holding element proxies bound to that driver, every thread targeting the same device and the same automation port.
That's an architectural problem, not a matter of tuning waits.
I spent the last few months building one in Java and writing up each step. Nine parts, one codebase, starting from an empty directory:
🏗️ The architecture principles behind every later decision — SRP, OCP, DIP, and what "robust" actually means
📦 Maven multi-module layout — and when a single module is the better call
🚗 DriverManager owning the Appium session, BasePage wiring PageFactory
🥒 Cucumber and Spring — feature files, step definitions, CucumberSpringConfiguration
📱 One screen object class driving both Android and iOS
⚙️ Spring profiles for platform, device, environment and test phase
🧵 ThreadLocal drivers, @ScenarioScope beans, a device pool with port isolation
One mechanism worth knowing if you're going cross-platform: AppiumFieldDecorator reads the annotations on each field and selects by driver type at runtime. Declare @AndroidFindBy and @iOSXCUITFindBy on the same field, and an AndroidDriver session reads the first and ignores the second — an IOSDriver session does the reverse. You keep one screen object class and one set of step definitions, and switch platforms through configuration alone.
Every hands-on part ships with a complete, runnable code workspace.
👉 Read the full guide here: https://www.mobile-automation.io/build-a-mobile-test-automation-framework/
Top comments (0)