Your suite passes on one emulator. You boot a second one, flip parallel execution on, and everything falls apart — SessionNotCreatedException, port-bind errors, scenarios that pass alone but fail together, workers sitting idle while the run somehow takes longer.
Thread-safe test code isn't enough. Once two Appium sessions run on the same host, they compete for automation server ports and for the devices themselves. Both need to be handed out deliberately.
Here's what the guide walks through:
🎯 Building a DevicePool on a BlockingQueue so each scenario leases exactly one device — and blocks instead of over-subscribing
🔌 Port isolation done right: appium:systemPort for UiAutomator2, appium:wdaLocalPort for XCUITest
⚙️ Profile-gated YAML (device-pool.yml) so adding a device is a config entry, not a code change
🚦 Turning parallelism on properly in junit-platform.properties
🔁 Retrying failed scenarios at the Maven Surefire level — and why it can't live in application code
🧯 A failure-mode table mapping six common parallel symptoms to their actual cause
One thing worth knowing now: Cucumber's dynamic parallelism strategy scales workers to your CPU cores. That's the right default for unit tests and completely wrong for mobile — your constraint is devices, not cores.
Use fixed, and set parallelism equal to your device-pool size. Set it higher and you get workers blocked on an empty pool; set it lower and you're paying for devices you never use.
The full walkthrough includes the pool implementation, the scope-and-lifetime table for every shared concern, and realistic speedup numbers from 2 up to 10 devices.
👉 Read the full guide here: https://www.mobile-automation.io/mobile-parallel-testing-part-2/
I write practical guides on mobile test automation and AI tooling at mobile-automation.io (https://www.mobile-automation.io/). If this was useful, feel free to follow along.
Top comments (0)